- From: Peter van der Noord <peterdunord@gmail.com>
- Date: Fri, 20 Jul 2012 20:30:21 +0200
- To: Chris Wilson <cwilso@google.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
- Message-Id: <1A60DD2F-9725-4CEF-93D1-60CDBB3AB863@gmail.com>
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 >> >> >> >> >> >
Received on Friday, 20 July 2012 18:30:50 UTC