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

[Bug 17795] Behavior of multiple connections to same node needs to be explicitly defined

From: <bugzilla@jessica.w3.org>
Date: Thu, 19 Jul 2012 15:41:15 +0000
Message-Id: <E1Srsqp-00042o-LS@jessica.w3.org>
To: public-audio@w3.org

--- Comment #3 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2012-07-19 15:41:15 UTC ---
(In reply to comment #2)
> 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.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 19 July 2012 15:41:22 UTC

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