Re: Behavior of source nodes on connect/disconnect

On Sep 12, 2013, at 4:24 PM, Chris Wilson <cwilso@google.com> wrote:

> On Thu, Sep 12, 2013 at 3:14 PM, Raymond Toy <rtoy@google.com> wrote:
> The patch cord idea is very intuitive.  I think the implementation in Blink, however, is a bit troublesome since the destination pulls on the graph to get data, and if a cord is not connected, it never gets pulled. I'm not sure how to do this effectively.
> 
> Does the spec imply that this is how it works? I couldn't find anything definitive.
> 
> Probably not.  At one point this was definitely not how Chris thought about connections.  :)

I’m going to have to take up the mantle of Chris and disagree with you strongly here.  Disconnected nodes are disassociated from the graph entirely.  They do not participate in rendering to the destination node, and they no longer are connected to the destination node’s timeline.

There are philosophical and practical reasons for this.  

Philosophically speaking, disconnected nodes are collected by GC because they are no longer active. But if disconnected nodes continue to "play", we would either be GCing active objects, or not GCing disconnected objects, effectively leaking nodes with no end time.  Neither of which are good options.

Practically speaking, disconnecting a sub-graph is the only way deleopers can "pause" playback. If we force disconnected nodes to continue playing, the only way to pause playback would be to entirely tear down and re-create a subgraph.

My answers:

> >If you have a (long) source node that has started playing and then you disconnect it (completely) after 1 sec from one part of the graph and then wait for, say, 1 sec, and connect it to a different (or same?) part of the graph, what should happen?
> 
> You would "hear" it continue playing (so, from approximately 2 secs in to the source node content).

I disagree.  It may or may not continue playing, but if it does, it plays starting from when it was disconnected, or 1 sec in this example.

> >A different scenario:  You've started playing a source node, and then completely disconnect it from the graph and then add a onended listener.  What should happen? Does the onended listener get called when the source would normally end?
> 
> If you've added an onended listener, that keeps the node alive, and it would fire when the node finished playing (despite it having been disconnected previously).

No, it’s timeline is not progressing, so it does not emit a ‘ended’ event.

> >Another scenario:  Say you have a source node attached to a sub graph that isn't currently attached to the destination.  If you start(0) the source node, and then later on connect the subgraph to the destination, what should happen?
> 
> It "continues" from wherever it is in playback when you connect() it.  That includes time side effects - e.g. if the subgraph includes a convolution or delay node, those effects from previous data would be applied.

The subgraph was not rendering when it was connected(), so it’s timeline was not progressing.  It will behave as if you called start(0) after connecting the subgraph.

> >Or say you don't connect the subgraph, but have an onended listener for the source.  The listener should get fired, once the source is started?
> 
> Once the source has finished, yes.  (if the source is a 5 second buffer, you would get onended fired approximately 5 seconds after start(0) is called.)

This is the same situation as the 1st: it is not connected, so it is not playing, and cannot end.

-Jer