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