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

I think we might want to discuss in the group the idea of having gate
signals; I'm not convinced running (and detecting changes in) audio-rate
signals is the best way to represent triggers.  All of your scenarios below
are gate inputs/outputs other than one.

On Wed, Jul 18, 2012 at 10:30 AM, Peter van der Noord <peterdunord@gmail.com
> wrote:
>
> 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).
>
> I would definitely use inputs/outputs *a lot*, and more than just for
> channel mixing/splitting, although mixers are indeed the most obvious
> example. But my flash synth has numerous other modules that have more than
> 1 in/out.
>
> - clock multiplier: 1 in, 8 out. Creates x2, x3, etc mutiplications of an
> incoming clock pulse
> - delay module: 2 in, 1 out. Additional input for syncing the delaytime
> with a clock (or lfo)
> - ring modulator (multiplies two signals): 2 in 1 out
>

You can already do this with a Gain node, since the .gain is an AudioParam
that you can connect an audio-rate signal to.


> - envelope with combined gaincontrol (you can apply the envelope directly
> on a signal): 2 in (trigger and signal) 2 out (the envelope itself and the
> enveloped signal)
> - stepsequencers send a gate out whenever they've reached the end
>
> I must add that some of can be done with parameters in the api (which act
> like inputs), but that's just for the inputs.
>
> 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);
>
>
> Ah, the first parameter is optional as in it defaults to output 0. Got it.
> Still, i find it a strange one... I must admit that i'm very fond of
> precise and descriptive functionnames, and node.disconnect() (without
> params) would imply to me that it disconnects the node. But actually it
> means: disconnect merely output 0. I find that confusing.
>
> Anyhow, if that method works like that (with the addition for supplying
> additional params for the destionationnode and destinationinput) i can work
> with it. Can i still suggest a context.removeNode(node) which completely
> removes a node and its connections?
>

Well, "completely remove" seems to imply more than just disconnection;
other code may still hold references to the node, so it still has to be
there.  I think hitting all the critical scenarios for disconnection is
probably a better pattern.