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:31:29 -0700
Message-ID: <CAJK2wqX=H-jf97B-MOWLP20V4cQJwpFziONgSVqN0=K775D=tw@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 3:26 PM, Peter van der Noord
<peterdunord@gmail.com>wrote:

> > 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.
>
> The idea is that creation of patches is *always* done in the editor,
> hovering over an input or output will immediately show its name and
> description. connections will never be made by typing code. (editor
> saves a patch, and you can put it behind your site or game by loading
> the file into the engine)
>

I disagree entirely with the supposition that "connections will never be
made by typing code."


> >> - 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.
>
> Hmmm, then i don't think i understand your example, could you explain
> what happens in there?
>

Your comment about "communicating/synchronizing between those two [nodes]"
led me to believe you thought I was saying they were completely
independent, autonomous objects.  I would see them, in that case, as just
being convenient API representations of a signal input or output tied to
the original node (the one that has a control, clock, whatever signal
exposed on it).

-C
Received on Friday, 20 July 2012 22:31:58 GMT

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