W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

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

From: Chris Wilson <cwilso@google.com>
Date: Thu, 19 Jul 2012 08:29:43 -0700
Message-ID: <CAJK2wqX7mU1kytAABNF2jRGPmEhqnme_2wZ5yrv-pSHo=P94LA@mail.gmail.com>
To: Peter van der Noord <peterdunord@gmail.com>, public-audio@w3.org
(Sorry, I inadvertently removed the list from this thread.)

On Thu, Jul 19, 2012 at 12:13 AM, Peter van der Noord <peterdunord@gmail.com
> wrote:

>
> > 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 you can call those methods from inside your JSnode implementation.


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

I don't think there is a difference, really.  (Obviously, AudioParams have
automation support as well.)


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

I think I meant "it seems like you're implying the INPUT connections would
be removed from that node as well?"
Received on Thursday, 19 July 2012 15:30:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 15:30:20 GMT