W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: JavaScriptNode interface

From: Chris Lowis <chris.lowis@bbc.co.uk>
Date: Tue, 08 May 2012 17:03:29 +0100
Message-ID: <4FA943D1.7070101@bbc.co.uk>
To: Chris Rogers <crogers@google.com>
CC: public-audio@w3.org
On 02/05/2012 18:49, Chris Rogers wrote:
> Thanks for your comments Chris.  I'm sorry for the confusion here and
> hope I can clear some things up.

Thanks Chris, that was really useful. It looks like the JavascriptNode 
will work a little differently to other nodes in that case. I guess 
we'll just have to be explicit with the documentation and some examples 
to explain the difference.

> What I think you'd like here is two separate inputs to the node, each of
> which is stereo (is 2-channel).  Currently the JavaScriptAudioNode
> specification *always* has 1 input and does not support multiple inputs.

Yes, that's what I was thinking, to make it more consistent with the 
'native' nodes.

> But, since you'd like to connect two discrete stereo streams, you'd
> have to use an AudioChannelMerger to first merge them into one 4-channel
> stream.  This isn't really ideal, but is certainly workable.

Yes, I can see how this would work. In our example we were having to do 
a lot of "additions" in javascript nodes so we ended up with a lot of 
mergers and splitters. The more functionality we can put into native 
nodes the less of a problem this will be.

> I think we can talk about extending the limitation of 1 input and 1
> output, and allow the ability to add further inputs and outputs.  I'm
> uncertain that we'll be able to do this directly in
> createJavaScriptNode(), since this would go back to the old model which
> confused people, and would also break a lot of pages already deployed.
>   But, I think we could add setNumberOfInputs() and setNumberOfOutputs()
> so these could be modified later on.  And then we'd also have to add
> accessors for the individual inputs/outputs. I think this can be done so
> that the current simple usage can be maintained, but more advanced uses
> (multiple inputs/outputs) can also be handled.

That sounds like a good idea - it would be a shame to break a lot of 
existing pages, but if there's a way to do this without breaking 
backwards compatibility, that would be great.

Thanks again for taking time to have a look at this,


Received on Tuesday, 8 May 2012 16:03:54 UTC

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