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: Chris Wilson <cwilso@google.com>
Date: Fri, 20 Jul 2012 15:15:36 -0700
Message-ID: <CAJK2wqWAccFSDMtvi5mtXKoVuwu_7xTuAmDEUXB8YwD0rZHDfw@mail.gmail.com>
To: Peter van der Noord <peterdunord@gmail.com>
Cc: "public-audio@w3.org" <public-audio@w3.org>
On Fri, Jul 20, 2012 at 2:24 PM, Peter van der Noord
<peterdunord@gmail.com>wrote:

> Actually, you easily could - there just aren't examples of this today.
>  You could easily expose AudioNode members of an AudioNode:
> interface ClockMultiplier : AudioNode {
>    AudioNode TwoX;
>    AudioNode FourX;
> }
>
> then you call .connect on those members.
>
>
> Encapsulating multiple nodes inside another one, that seems like an overly
> complicated way to do that, especially given the fact that inputs and
> outputs are really *exactly* what i need.
>

I'm not sure why you see it as overly complicated, since to me the
AudioNode interface only contains connect and disconnect.  It seems pretty
well suited for an encapsulation of making connections.  Using inputs and
outputs on nodes, on the other hand, is going to require you to remember to
connect output 4 when you want the clock sync output, to input 3 when you
want the sequencer clock.


> - i would have to write separate code in each of those inside nodes, and
> would have to create complicated instructions to be able to
> communicate/synchronize between those two, while what i want is to write
> simultanously to multiple outputs inside one bufferwrite loop.
>

Umm, not necessarily, no.  I didn't say they were SETTABLE - they're just
API exposure.


> What i don't understand why you discourage the use of inputs and outputs,
> while they exist (there's even a ticket in the tracker that says you should
> be able to create your own on a jsnode) and while they are exactly what i
> need.
>

Then use them; I'm not stopping you.  I never intended to prevent any
usage; all I insist on is that I want the single-input, single-output cases
as easy as possible.  I merely said I don't see using number i/os to
represent significantly semantically different connections as the best way
to do things.

-C
Received on Friday, 20 July 2012 22:16:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 22:16:05 GMT