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

> It's just being symmetric with connect() (which creates an outbound connection).
>  

That is true, and i do see where it comes from, but I think the problems have to do with sticking to previous ideas which do make good examples (look, it's as easy as "nodeA.connect(nodeB)") but which might not be the best approach in my humble opinion. I also see that my usercase is not everyone's, and i also see that changing core methods of an api isnt the the first option to choose, but I'm just hoping that there will be more functionality added with regards to removing and disconnecting.

My own interface is something like this: (and i do expose connections, which is nothing more than something with a sourceOutput and a destinationInput)

patch.addNode(nodeType)
patch.removeNode(node)
patch.addConnection(output, input)
patch.removeConnection(connection)

...with some functions and properties on transputs, which is the superclass of inputs and outputs, like:
transput.removeAllConnections()
transput.connections

i think it's clean, easy and practical.

>> *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.
> 
> Actually, you easily could - there just aren't examples of this today.  You could easily expose AudioNode members of an AudioNode:
> interface ClockMultiplier : AudioNode {
>    AudioNode TwoX;
>    AudioNode FourX;
> }
> 
> then you call .connect on those members.

Encapsulating multiple nodes inside another one, that seems like an overly complicated way to do that, especially given the fact that inputs and outputs are really *exactly* what i need.

- i would have to write separate code in each of those inside nodes, and would have to create complicated cunstructions to be able to communicate/synchronize between those two, while what i want is to write simultanously to multiple outputs inside one bufferwrite loop. 

- take a combined envelope/amplifier for example. It can generate an attack-decay (or whatever type) envelope. It has a trigger input, and an envelope output. Next to that, it has an input and output for a signal to immediately apply the envelope on. In my flash app, i have 1 buffer write loop in thatmodule that writes the envelope to its output, and also immediately applies that same envelopevalue on a signal (*if* there's something connected the the signal output - a check i would love to have in the api as well, to be able to prevent useless computations) and writes that to the other output. Splitting that up into two separate modules is not inviting.

- connecting them might be easily done with code, but as with your playground app, i'm writing a modular editor that just connects module X output A to module Y input B. So...on the outsidenode, i would *still* have to use inputs and outputs, because that's how my modules work: they have inputs and outputs and you connect any of them.

What i don't understand why you discourage the use of inputs and outputs, while they exist (there's even a ticket in the tracker that says you should be able to create your own on a jsnode) and while they are exactly what i need.