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 16:17:44 +0000
Message-Id: <E1SrtQ8-0000pU-1t@jessica.w3.org>
To: public-audio@w3.org

--- Comment #4 from Chris Wilson <cwilso@gmail.com> 2012-07-19 16:17:43 UTC ---
(In reply to comment #3)

> disconnect() could just remove one of the connections.

I would expect.  But we'd have to alter the API to return the number of
existing connections, or something, to tell if the nodes are still connected. 
(So you'd have some way of saying "REALLY disconnect these nodes".)

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

I'm not fundamentally opposed to the idea, but I think the API should be usable
in most cases without having to keep track of those identifiers.

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

The API *IS* predictable.  All I was saying is that the behavior needs to be
explicit in the spec.

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

I'm not suggesting at all that it WOULD fail.  It doesn't today - it just
doesn't create an ADDITIONAL, duplicate connection (thereby doubling the gain,
which would be just as unpredictable, and IMO less usable.)

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 16:17:49 UTC

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