Re: [Bug 17793] New: AudioNode.disconnect() needs to be able to disconnect only one connection

Right.  The confusing bit is that each output from a node can fan out to
multiple other nodes; these fanned-out connections are NOT referred to as
multiple outputs, nor are multiple connections connected to a single node
necessarily connecting to anything but a single input.

>From the spec:  "An AudioSourceNode has no inputs and a single output. An
AudioDestinationNode has one input and no outputs ... Most processing nodes
such as filters will have one input and one output."  In point of fact -
the ONLY node type in the current spec that can have more than one input is
the AudioChannelMerger, and the only node type in the current spec that can
have more than one output is the AudioChannelSplitter.  They are the only
types that offer these separate inputs or outputs.

This is a separate concept from the summing of multiple
inputs<https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#SummingJunction-section>and
the fan-out of multiple node connections from a single output.

See inline...

On Tue, Jul 17, 2012 at 1:51 PM, Peter van der Noord
<peterdunord@gmail.com>wrote:

> Ok, now i am even more confused. Please tell me where i'm going wrong.
>
> >  The "input" and "output" parameters on connect & disconnect were
> initially quite misleading to me - because *you will only use them for
> nodes that explicitly offer separate inputs or outputs*
>
> What i assumed (and what you seem to say that in the quote above) is:
>
> - nodeA.connect(nodeB)            connects output 0 of A to input 0 of B
> - nodeA.connect(nodeB, 1)        connects output 0 of A to input 1 of B
>

Note that this can ONLY work if nodeB is an AudioChannelMerger - no other
node type would have an input[1] in the current spec.

 - nodeA.connect(nodeB, 1, 2)    connects output 2 of A to input 1 of B

Again, correct - although this would throw an exception if nodeA were not
an AudioChannelSplitter with > stereo, OR if nodeB were not an
AudioChannelMerger of at least stereo.  (Because otherwise they wouldn't
have the requisite inputs/outputs.)

To me this is also what the draft says: "The output parameter is an index
> describing which output of the AudioNode from which to connect."
>
> But then you say that these indices "refer to different "channels" of a
> connection.". To me, these two remarks contradict eachother. What are the
> indices: inputs/outputs or channels (of a connection).
>
> Am i overlooking something?
>

No, you're just making the same mistake I did at first - confusing the
"output" and "input" parameters with an index into the fan-out of a node
that's connected to a bunch of other nodes, or an index into the
summing-junction of multiple nodes connecting to a single node.

The input and output indices in the current spec are only really relevant
when using Splitters and Mergers.  You should ignore the statement I just
made - referring to the different "channels" of a connection - because it's
not quite appropriate, unless applied to Splitters and Mergers.  (You can't
use the output index to get the left channel coming off an
AudioBufferSourceNode, for example.)

-Chris



> 2012/7/17 Chris Wilson <cwilso@google.com>
>
>> The "input" and "output" parameters on connect & disconnect were
>> initially quite misleading to me - because you will only use them for nodes
>> that explicitly offer separate inputs or outputs (notably - the
>> AudioChannelSplitter and AudioChannelMerger).  These indices do NOT refer
>> to the fan-out of connecting one node to multiple other nodes, or the
>> mix-in of connecting multiple nodes to one "destination" node; they refer
>> to different "channels" of a connection.  Therefore, you CAN connect one
>> output to two different inputs on another node; for example, you might do
>> this if you wanted the left channel from one node to be copied to the right
>> AND left channels in another node.
>>
>> For all scenarios where you are not explicitly interested in the multiple
>> channels, you don't need to supply these parameters at all.  Perhaps they
>> should be renamed "channels" for this reason, I don't know.
>>
>> So, if you have this case
>>
>> nodeA.connect( nodeB );
>> nodeA.connect( nodeC );
>>
>> there is currently no way to disconnect nodeA from nodeB, without also
>> disconnecting nodeA from nodeC.
>>
>> And yes, I did explicitly test to make sure that making multiple
>> connections from one node to another does not sum up the connections -
>> e.g.,
>>
>> nodeA.connect( nodeB );
>> nodeA.connect( nodeB );
>>
>> gives the same output as
>>
>> nodeA.connect( nodeB );
>>
>> It does not explicitly fail, it is just ignored.
>>
>> On Tue, Jul 17, 2012 at 11:51 AM, Peter van der Noord <
>> peterdunord@gmail.com> wrote:
>>
>>> > Recommended solution:
>>> > - there should be a way to remove a single connection (by supplying the
>>> > destination node to be disconnected, since there can only be one
>>> connection to
>>> > a given destination node [tested]).
>>> >
>>> > E.g.: the IDL for disconnect should read:
>>> >
>>> >         void disconnect(in [Optional] AudioNode destination, in
>>> [Optional]
>>> > unsigned long output = 0)
>>> >             raises(DOMException);
>>> >
>>> > this lets us keep most compatibility - node.disconnect() will still
>>> remove all
>>> > connections.
>>>
>>> I'm confused now.
>>>
>>>
>>> " node.disconnect() will still remove all connections."
>>>
>>> Is this the case? That would help me a lot. I only now see in the draft
>>> that the in-parameter is optional, so: does not supplying any params to the
>>> disconnect method remove the whole node with every connection to and from
>>> it like that uote says? If so, that is not mentioned in the explanation in
>>> the draft, it's even incorrect:
>>>
>>> Disconnects an AudioNode's output.
>>>
>>> The output parameter is an index describing which output of the
>>> AudioNode to disconnect. An out-of-bound value throws an exception.
>>> Then: "(by supplying the destination node to be disconnected, since
>>> there can only be one connection to a given destination node [tested])."
>>>
>>> I was already wondering what would happen if i tried to connect the same
>>> output and same input twice (i guessed it would fail...does it?) but this
>>> implies even more. Nodes can have multiple inputs and outputs, and by
>>> reading this sentence i understand i wouldn't be able to connect for
>>> example one output to two different inputs on another node. That can't be
>>> right, i think you should supply a node *with* the index of the input,
>>> instead of just the node.
>>>
>>> Peter
>>>
>>
>>
>