W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

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

From: Peter van der Noord <peterdunord@gmail.com>
Date: Fri, 20 Jul 2012 18:54:00 +0200
Message-Id: <FCB24B45-6B1E-430A-973C-21BCE135902C@gmail.com>
Cc: "public-audio@w3.org" <public-audio@w3.org>
To: Chris Wilson <cwilso@google.com>
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
> 
> 
> 
> 
> 
Received on Friday, 20 July 2012 16:54:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 16:54:29 GMT