- From: Chris Rogers <crogers@google.com>
- Date: Tue, 8 May 2012 11:53:06 -0700
- To: Chris Lowis <chris.lowis@bbc.co.uk>
- Cc: public-audio@w3.org
- Message-ID: <CA+EzO0nkThccPgikbpUOxQx-2V5+1pkQx_grdPJRhDw_HpP0iA@mail.gmail.com>
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. Chris
Received on Tuesday, 8 May 2012 18:53:38 UTC