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

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
- nodeA.connect(nodeB, 1, 2)    connects output 2 of A to input 1 of B

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?



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