Re: Disconnect outputs from specific inputs

First of all - I agree, the current connect/disconnect specification is
less than ideal.  I've had a couple of conversations with Chris (Rogers,
obviously) about this.  I also had to deal with this problem in the
WebAudioPlayground app (webaudioplayground.appspot.com) - when you click on
a connection link to remove it, it has to see if there are any other
connections to re-initiate.

The one problem here is the underlying problem that hasn't been clearly
specified yet. This can be described as "What happens when a playing node
is temporarily disconnected?" - or, conversely, "If you play a node, and no
one is listening (aka connected), does it really play?".

This first came to my attention when I was working with Z Goddard on the
Fieldrunners article for HTML5Rocks (
http://www.html5rocks.com/en/tutorials/webaudio/fieldrunners/) -
particularly, read the section entitled Pausing
Sounds<http://www.html5rocks.com/en/tutorials/webaudio/fieldrunners/#toc-pausing>.
 In short - they'd noticed that if you disconnected an audio connection, it
paused the audio "stream".  I thought this seemed pretty wrong - knowing
what I knew about how automation on AudioParams works - and went and talked
to Chris, and sure enough, he said it was a bug.

His take was that if you disconnect a playing audio stream, it should
probably go back and set the state for the root AudioBufferSourceNode to
FINISHED_STATE; in short, that you shouldn't be able to do this.  I
understand why - it radically simplifies some of the other audio
manipulations - but my mental model of connections as an API user still
really wants to be "they're just like plugging 1/4" audio cables between
hardware units," despite knowing that is not the case.

At any rate, I brought up the disconnect() problem ("I want to remove a
connection to one effect - but disconnect() will remove all connections") -
he suggested we would probably need a batch connection operations system.
 Chris, as I said before, is on vacation right now; I think we should have
a discussion about this when he's back, on the teleconference.

-Chris(2)

On Mon, Jul 16, 2012 at 5:52 AM, Peter van der Noord
<peterdunord@gmail.com>wrote:

> I agree on this one, the disconnecting implementation is quite unhandy.
> When i want to remove a node from the graph, i have to (if i understand the
> api correctly)
> - iterate through all outputs of the node and disconnect them (doable)
> - check every connection in the graph if it has a connection to either an
> input or a parameter of the module, and disconnect the output that leads to
> it (thus also potentially disconnecting connections that dont lead to said
> module).
>
> This is cumbersome, especially when there's no feedback to retrieve about
> the current state of the graph for debugging.
>
> In my humble opinion:
> - there should be a method to remove a module from the context (and
> obviously clearing all connections)
> - there should be a way to get the connections from an input or output
> - there should be a way to remove a single connection (by supplying a
> connection)
>
>
> Peter
>