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

Re: [web-audio-api] Behavior of multiple connections to same node needs to be explicitly defined (#143)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:53 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/143/24244476@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17795#2) by Robert O'Callahan (Mozilla) on W3C Bugzilla. Thu, 19 Jul 2012 15:41:15 GMT

(In reply to [comment #2](#issuecomment-24244468))
> If you allow multiple connections between two nodes*, then you'll have to
> provide an identifier for that connection, and enable the disconnect() to take
> that identifier (and require developers to hang on to that identifier).  Or,
> said another way - if connect() always adds another connection, even if it
> already exists, then what does disconnect() do, and how do you know when you
> are really disconnected?

disconnect() could just remove one of the connections.

(I do think having identifiers for connections is a good idea though. MSP has them --- InputPorts --- and it lets you set parameters on connections, which seems useful.)

> If there's a scenario for making multiple connections between two nodes*, I'm
> open to hearing it; I just couldn't think of any.  I would presume it would
> just effectively double the gain, which of course is easy to do in other ways.

The API should behave predictably even when used in unexpected ways, even ways that aren't the best approach to any given use-case.

Imagine if some module builds an AudioNode A, and then two other modules independently get hold of A and try to play it by connecting it to the DestinationNode. It would be confusing to have one of those operations unexpectedly fail.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/143#issuecomment-24244476
Received on Wednesday, 11 September 2013 14:30:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:11 UTC