Re: Behavior of source nodes on connect/disconnect

On Fri, Sep 13, 2013 at 8:49 AM, Chris Wilson <cwilso@google.com> wrote:

> Note that you wouldn't be "not GCing objects" because they're (silently)
> playing - if you have a reference to them, you need to keep them around
> anyway; if you DON'T have a reference to them, there's no way you could
> ever reconnect them, so you can go ahead and reconnect them.
>
> Hmm, that does mean onended should only fire if they're connected; my bad
> there.
>

Re: this, if onended fired on a disconnected node it would allow you to
'recover' or 'resurrect' a dead (no live references in JS heap) node by
pulling the this-reference/event target out of the event arguments in the
onended handler. If the onended handler happened to be getting fired by a
GC finalizer... that would be pretty bad.

On the other hand, that does put us back in the spot where onended doesn't
fire sometimes, and I thought people had voiced strong opinions that it
should always fire.


Other than that, I just want to +1 all of Jer's comments about the
described behavior for disconnected nodes being undesirable and somewhat
strange. It doesn't seem like a good solution, even if I understand that
there are probably reasons why you prefer it.

Also, in the past I saw strong statements from either cwilson or crogers
(sorry, I don't remember which) to the effect that pausing was
intentionally not supported in the design of the Web Audio API, explicitly
*because* it doesn't make sense in the patch cable model - so it's weird to
see the opposite stated now based on the same justification. IIRC the
justification used at the time was that an effect pedal or recorder or
mixer is not going to suddenly 'pause' functioning because of a cable being
disconnected, and I do agree with that logic. (Though the idea of
constraining a games/multimedia realtime mixing API in order to be 'like
hardware' is pretty odd to me)

On the other hand, it is at least possible to "pause"
AudioBufferSourceNodes in a general sense, so I can't complain that pausing
is impossible for my use cases. But it does seem like it comes up a lot, so
maybe it should be supported in a formal manner instead of through 'back
doors' like it being a side effect of graph disconnection... I assume the
reason it is undesirable is that it eliminates the simplicity of having a
single global currentTime.