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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17795#3) by Chris Wilson on W3C Bugzilla. Thu, 19 Jul 2012 16:17:43 GMT

(In reply to [comment #3](#issuecomment-24244476))

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

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/143#issuecomment-24244481