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

Yes, EXCEPT connect() is one-way, and disconnect is currently the same.  I
do not think nodeA.disconnect() should disconnect inputs into nodeA.  So it
would be:
nodeA.disconnect() -> removes all outbound connections from nodeA's outputs
nodeA.disconnect(nodeB) -> removes all outbound connections from any of
nodeA's outputs to any of nodeB's inputs
nodeA.disconnect(nodeB, 1) -> removes all connections from nodeA's output 1
to any of nodeB's inputs
nodeA.disconnect(nodeB, 1, 2) -> removes any outgoing connections from
nodeA's output 1 to nodeB's input 2

TBH, though, I'm ambivalent about if this is done.  It seems like
additional complexity, when I really think multiple inputs/outputs *bundled
in this way* *will be fairly rare.

-Chris

*Note that the scenarios you were talking about before - specific gate
inputs, e.g. - would likely be exposed as separately-named parameters on
the nodes, not just as numbered inputs - the same way the named AudioParams
like .gain are exposed today.  The "inputs" and "outputs" really are
channels, to me.


On Fri, Jul 20, 2012 at 9:54 AM, Peter van der Noord
<peterdunord@gmail.com>wrote:

> Do you mean this behavior?
>
> nodeA.disconnect() -> removes all connections from nodeA's inputs and
> outputs
> nodeA.disconnect(nodeB) -> removes all outgoing connections to nodeB
> nodeA.disconnect(nodeB, 1) -> removes all outgoing connections from
> nodeA's output 1 to nodeB
> nodeA.disconnect(nodeB, 1, 2) -> removes all outgoing connections from
> nodeA's output 1 to nodeB's input 2
>
>
>
> Op 19 jul. 2012 om 21:45 heeft Chris Wilson <cwilso@google.com> het
> volgende geschreven:
>
> I see what you mean.  We could always define the defaults as -1, rather
> than 0, and have that mean "remove any/all".
>
> I'm inclined to make it easy to use in the single i/o case, since that is
> 90% of the API surface today.
>
> On Thu, Jul 19, 2012 at 11:31 AM, Peter van der Noord <
> peterdunord@gmail.com> wrote:
>
>> I did some more thinking about this part:
>>
>>
>> On Wed, Jul 18, 2012 at 2:24 AM, Peter van der Noord <
>> peterdunord@gmail.com> wrote:
>>
>>> 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)
>>>
>>
>> Heh.  Right you are, you would in fact have to (potentially) supply the
>> destination's input
>>
>>
>> I wanted to add that, in my opinion, the method should raise an exception
>> when it's not unambigously clear what to disconnect. But, thinking
>> further...this can't be done.
>>
>> Take the above connections as an example, and this most recently
>> suggested disconnect method:
>>
>> node.disconnect(node = null, outputindex = 0, inputindex = 0) with all
>> parameters optional.
>>
>> Now, let's say i want to remove the connection i made on the second line
>> (A out#0 to B in#1). Let's also assume that i somehow forgot that the other
>> connection going out of out#0 existed. I'd do:
>>
>> nodeA.disconnect(nodeB, 0);
>>
>> My thought was raising an exception here would be nice: "hey, you want to
>> remove a connection from an output, but there are more connections there so
>> i don't know which one to remove."
>>
>> But, since the optional third parameter (which defines the input#)
>> defaults to 0, there is no way to throw an exception, because the other
>> connection will simply be removed.
>>
>> And the method would react even differently when the first connection
>> wasnt connected to input #0 but to #2. Again i'm forgetting there are two
>> outgoing connections on output #0:
>>
>> nodeA.disconnect(nodeB, 0);
>>
>> Third parameter not supplied, defaults to 0, probably gives an error
>> because there's nothing there on input #0.
>>
>> The fact that all params are optional doesnt help in my opinion, it
>> leaves a lot of room for unnoticable mistakes. Does anyone else see this as
>> a problem, or am i the only one? :)
>>
>> Peter
>>
>>
>>
>>
>>
>