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

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 connection as well.

Referring to these cases as 'only really relevant when using Splitters and
> Mergers' makes them look like rare exceptions, but that's not important.
> Nodes just have a certain number of inputs and outputs, and you should be
> able to connect/disconnect them however you'd like. Apart from that, with
> the future possibility to create jsnodes with a given number of in/outs (as
> i nunderstand from the fact that it's listed here:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17533) it will be less
> rare.
>

I don't mean to make them sound like rare exceptions in terms of support; I
simply meant that in terms of grokking how connections work, not only can
you ignore the inputs and outputs until you need to understand Splitters
and Mergers, you will probably find it more understandable to do so... or,
of course, go learn Splitters and Mergers and multi-channel handling early
on.

That said, I don't think multiple inputs and outputs will be used very
heavily, even with support for them in JSNodes, outside of the obvious case
of multi-channel (stereo, 5.1, etc) audio, *most* of which is handled by
the native nodes automatically (or should be).

Also, i can see native nodes being added or changed over the years
> (compressor+sidechain input for example).
>

Of course.  (As an aside - I'd thought through sidechain inputs and
expansion (noise gating) recently, and after some thought I think all we
really need is for the "reduction" on a compressor to be available as an
AudioNode output, so it could drive a gain node directly.  (and make
compressors function without a connected output, a la Analysers.)  Or maybe
we should generically be able to connect AudioParams to other nodes, and
make it an AudioParam?)


> Still wondering what this does by the way: "node.disconnect() will still
> remove all connections.". Quoting myself: "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 quote says?
> If so, that is not mentioned in the explanation in the draft"
>

Sorry, I overspoke there a bit.  node.disconnect() will still remove all
outbound connections *from a particular output.*  It defaults to output 0,
which is of course the only output any node but a Splitter has, so in
general, it will disconnect a "normal" (i.e. non-splitter) node completely
in one go, but you're right that it won't work on a splitter.

To *generically *completely disconnect all of a node's outputs, though, you
can just do this:

for (var i=0; i<node.numberOfOutputs; i++)
    node.disconnect(i);

That would remove all outputs from any type of node.

-Chris