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.
>
>
I'm all for a discussion about some kind of gate implementation, although
those example you refer to were only to illustrate that i would use inputs
and outputs a lot on my own custom modules (regardless of their exact use).
But a gate *signal* implementation...to me, a signal is a signal,
regardless of its use, that's up to the receiving module. I can already
create gate signals, the api lets me freely write datainto a connection.
What i can't do Is easily trigger some events on native modules at the
moment, since they're all using methods for that.

But apart from that, i'd like to hear what others think of this subject.

And about gate and a-rate....i did implemented it myself this way with the
following reasoning: gates are often used for timing certain events. If you
would not do this at a-rate, a module responding to a gate would trigger
something slightly off-time, probably within acceptable limits. However,
modules that are connected more down the chain would get more and more out
of sync, which leaves you with a sync system that by definition can't sync.


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

I have been wondering about this a few times: what exactly is their
difference (input and an audio param at a-rate)? I saw in the issues list
that adding audio params yourself (to a js node) is a wanted feature, so if
i am them creating my own node....what's their difference? I could be
adding 5 inputs or 5 params....i can both connect a signal to it, and i can
both read from them inside the module.



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

But that is always the case, no matter which api you use, it's up to the
programmer to remove references. Maybe the function should be called
disconnectNode? I'd just like (an in my opinion logical) method to
disconnect a node from the graph. I don't think there's any api dealing
with graphs that doesnt let you do that with a single command.

Peter