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

Ok, that's clear. But going back to what got us here, the suggested
disconnect function:

 void disconnect(in [Optional] AudioNode destination, in [Optional]
> unsigned long output = 0)
>             raises(DOMException);

...doesnt seem like it can unambiguously handle all cases,

nodeA.connect(nodeB, 0)    -> A out#0 to B in#0
nodeA.connect(nodeB, 1)    -> A out#0 to B in #1

Supplying an output and a destinationnode is not enough to pinpoint any of
the two connections, you will *have* to supply the destination's input
index as well if you want to remove one (or do i think i'm understanding
this, while in fact i am not)

Referring to these cases as 'only really relevant when using Splitters and
Mergers' makes them look like rare exceptions, but that's not important.
Nodes just have a certain number of inputs and outputs, and you should be
able to connect/disconnect them however you'd like. Apart from that, with
the future possibility to create jsnodes with a given number of in/outs (as
i nunderstand from the fact that it's listed here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17533) it will be less rare.
Also, i can see native nodes being added or changed over the years
(compressor+sidechain input for example).


Still wondering what this does by the way: "node.disconnect() will still
remove all connections.". Quoting myself: "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 quote says?
If so, that is not mentioned in the explanation in the draft"


Peter

2012/7/18 Chris Wilson <cwilso@google.com>

> 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
>>>>
>>>
>>>
>>
>