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 20:30:21 +0200
Message-Id: <1A60DD2F-9725-4CEF-93D1-60CDBB3AB863@gmail.com>
Cc: "public-audio@w3.org" <public-audio@w3.org>
To: Chris Wilson <cwilso@google.com>




Op 20 jul. 2012 om 19:54 heeft Chris Wilson <cwilso@google.com> het volgende geschreven:

> 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

Hmm, we're clearly not agreeing on this. I know i'm repeating myself, but i think it's very strange that if you say disconnect to a node, that it disconnects its outputs. I could live with it if there *was* a way to simply disconnect a node (everything connected to it).


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

I disagree, i will still use them a lot - although me being the only one is still not much, i admit ;) 

I know that i can use params (instead of an input), but there's no way to do something similar with an output. And since i will be using multiple outputs, i will probably not use param-instead-of-inputs, because that will add unnecessary complexity.

But, the thing that struck me when i read your *note... how do i even disconnect something that's connected to a param?


> 
> 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
>> 
>> 
>> 
>> 
>> 
> 
Received on Friday, 20 July 2012 18:30:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 18:30:51 GMT