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: Peter van der Noord <peterdunord@gmail.com>
Date: Thu, 19 Jul 2012 19:26:52 +0200
Message-Id: <D7F3A87B-5C60-4893-BDE7-0C952A2FF1BB@gmail.com>
Cc: "public-audio@w3.org" <public-audio@w3.org>
To: Chris Wilson <cwilso@google.com>

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

True, for my own modules that would work, but i wouldn't be able to use some of the native nodes then, since certain functions can only be triggered by their methods.

> > 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?"

Yes, that was what i was implying: there should be a simple method that fully disconnects a node. Inputs and outputs.

Received on Thursday, 19 July 2012 17:27:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:10 UTC