- From: Chris Wilson <cwilso@google.com>
- Date: Thu, 19 Jul 2012 08:29:43 -0700
- To: Peter van der Noord <peterdunord@gmail.com>, public-audio@w3.org
- Message-ID: <CAJK2wqX7mU1kytAABNF2jRGPmEhqnme_2wZ5yrv-pSHo=P94LA@mail.gmail.com>
(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 UTC