Re: JavaScriptNode interface

Thanks for your comments Chris.  I'm sorry for the confusion here and hope
I can clear some things up.

On Wed, May 2, 2012 at 6:19 AM, Chris Lowis <chris.lowis@bbc.co.uk> wrote:

> Matt Paradis and I have been thinking about the interface to the
> JavaScript node, after noticing a difference between the current
> stable Chrome version of the API and the one in the Canary
> (development) build.
>
> In the former a JavaScriptNode could be created like so:
>
> : node = createJavaScriptNode(1024, 0, 1)
>
> For a node with a single output channel. The individual streams in the
> channel could be addressed inside the process callback using
>

This is not the terminology I use.  In the current JavaScriptAudioNode,
there is always 1 input
and 1 output.  The "constructor" arguments define the number of channels
for this (single) input, and
the number of channels for this (single) output.  So I don't understand
"individual streams in the channel".
The "channel" is the very lowest elementary unit.  There are no streams
"in" the channel.


>
> : e.outputBuffer.getChannelData(**0)
> : e.outputBuffer.getChannelData(**1)
>

Yes, this was a bug (shouldn't have allowed access to the 2nd channel)


>
> and so on. Chris R mentioned earlier that this is due to the current
> implementation defaulting to 2 streams irrespective of the arguments
> provided to createJavaScriptNode. In the Canary implementation this
> has been changed so that the above code only works (getChannelData(1)
> returns Null otherwise)


Yes, this has now just been fixed to be in line with the spec.



> if the javascript node is created with
>
> : node = createJavaScriptNode(1024, 0, 2)
>
> That is, 2 *streams* are specified in the output.
>

Yes.


>
> It is unclear to us how this interface will work in the case where a
> number of streams are multiplexed into a number of channels. For
> example say two stereo (2-stream) channels are to be processed inside
> a javascript node; would the node be instantiated with 4 inputs (streams)
>

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.
 Earlier in the specification, I had a more complex API which allowed
multiple inputs and outputs, and the arguments to createJavaScriptAudio()
defined how many inputs and outputs (instead of how many channels for the
single input and single output).  But, because so many people were confused
with this idea and always thought that the arguments meant "number of
channels", I simplified this to its current form to match people's
expectations.


>
> : node = createJavaScriptNode(1024, 4, 4)
>

So, in this case you're creating a 4-channel input and 4-channel output.
 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.


>
> or two inputs (channels)
>
> : node = createJavaScriptNode(1024, 2, 4)
>
> ?
>
> How would the individual streams within each channel be accessed
> within the node? One solution would be for getChannelData to return an
> array of stream objects making it possible to iterate over each stream
> in a channel. This would allow a javascript node to be written to work
> with channels containing any number of streams. The interface to
> createJavaScriptNode would then accept the number of channels rather
> than the number of streams.
>

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.

Cheers,
Chris