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

Re: JavaScriptNode interface

From: Chris Rogers <crogers@google.com>
Date: Tue, 8 May 2012 11:53:06 -0700
Message-ID: <CA+EzO0nkThccPgikbpUOxQx-2V5+1pkQx_grdPJRhDw_HpP0iA@mail.gmail.com>
To: Chris Lowis <chris.lowis@bbc.co.uk>
Cc: public-audio@w3.org
On Tue, May 8, 2012 at 9:03 AM, Chris Lowis <chris.lowis@bbc.co.uk> wrote:

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

Hi Chris, I think having multiple inputs and outputs (we already support
multiple channels) will be interesting and we can explore ways to support
it as I mention, but I'm guessing most people will use the simple form of 1
input and 1 output as it is today (where the input and output can be
multi-channel).  So, I'm interested in providing a "constructor" for this
node which is easy to use and understand for this very common case, not
just for backwards compatibility.

Received on Tuesday, 8 May 2012 18:53:38 UTC

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