- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Fri, 13 Sep 2013 07:39:45 +0300
- To: Chris Wilson <cwilso@google.com>
- Cc: Raymond Toy <rtoy@google.com>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAJhzemXvCukLfba6FxQcW9C1GonaMDq4d83w+W8OmQGRraaVWQ@mail.gmail.com>
On Fri, Sep 13, 2013 at 12:59 AM, Chris Wilson <cwilso@google.com> wrote: > I believe the current understanding is that the nodes would all keep > playing as if they were connected; that is: > > >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). > This sounds like a terrible idea. Would that mean that the ScriptProcessorNode would keep firing onaudioprocess while it's not connected? If not, then ScriptProcessorNode is again further away from being usable for polyfilling native nodes. That would also mean that disconnected fire-and-forget nodes would be unnecessarily eating CPU until garbage collector eats them. While the patch cord idea tickles my mind as a musician, disconnecting / reconnecting cords during the session is often an undesired event due to popping and other stuff. And if you do want to achieve that unpleasant effect anyway, you couldn't replicate the pops anyway, so might as well use a gain node and turn it to 0 when you want to mute and 1 when you want to continue. What's the use case that cannot be achieved without this weird feature that has quite unpleasant implications? GC observation is the only one I can think of (start a lot of workers measuring how long one cycle of infinite loop takes, fire and forget a convolution node and see when the execution speed of the cycles in one of the workers grows). Also worth noting that other graph DSP software I've used doesn't do this, but instead if you for example reconnect a delay node, it would keep playing back the feedback it had when disconnected. I also once had a cheap delay pedal (I think it was a Behringer) that did this. To me this doesn't sound like something worth doing. Cheers, Jussi > >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). > > >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. > > >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 model is akin to plugging patch cords between nodes, which I've > always found the most intuitive from a developer perspective; Chris > disagreed with me on this for quite a while, but I think he'd come around. > > -Chris > > > On Thu, Sep 12, 2013 at 2:46 PM, Raymond Toy <rtoy@google.com> wrote: > >> 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? >> >> 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? >> >> >> On Thu, Sep 12, 2013 at 1:51 PM, Raymond Toy <rtoy@google.com> wrote: >> >>> While fixing a different issue in Chrome's webaudio, the following >>> questions came up. >>> >>> 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? Does the node start playing again? What does >>> it play? The source starting at time 2 sec? >>> >>> 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? >>> >>> I think these are not scenarios that would normally occur, but it came >>> up during a review, and I didn't know the answer. >>> >>> Help! >>> >>> Ray >>> >>> >> >
Received on Friday, 13 September 2013 04:40:12 UTC