Re: Question about channels and merger on destination

Yes, i assumed having a merger with 3 inputs would always output a
3-channel stream, with all inputs mapped to their individual stream, but
unfortunately it does a lot of reconfiguration on the outputstream.

Btw, in my second construction (http://i.imgur.com/MLtnQ.png), the bottom
gains can be left out, but i think something else is necessary to get it to
work: my jsnode *has* to write all buffers of all channels, in order to
prevent the following channelsplitter from reorganizing the signal. I can
easily check what output is connected but i'd still have to write 0s to
those buffers, otherwise the signal might end up in the wrong output. At
least, that's how i understand it.

A question about that, if anyone knows: if i have a jsnode with a 2-channel
output, and i only write to one of those, what type of signal does that
result in? Will i have 2 channels with one of them being filled with 0s, or
will i have a mono output?

Peter

2012/7/23 Alessandro Saccoia <alessandro.saccoia@gmail.com>

> > No! Hmmm, that makes my plan impossible then i guess. For the time
> being, I had created a system where custom modules with more inputs or
> outputs would get wrapped into a construction like this...
> >
> > http://i.imgur.com/sjObQ.png
> >
> > ...so i would have access to those in/outs through the channels of the
> (js) audionode, but if the merger and splitters behave like that i don't
> think that's possible.
>
> Yeah, I see what you mean. Still, it would like someone to confirm what I
> said before you end up changing your approach.
> From your diagram it looks like that you were expecting the data at the
> merger output to be stereo by default, right?
>
>

> The merger just merges all its inputs channel in a bigger bus to
> accomodate all these streams, in order for them to be processed with a
> single chain of audionodes at later stages.
> To do what you mean to do, you could wrap the merger into a custom object
> that has 3 inputs: left, right and stereo. Left and right would need to be
> connected to a panner node (that always outputs stereo) that places them at
> the two extremes of the stereo image. The panner and the stereo input would
> join into a common gain node that is the final node of the object.
> Even if this looks a bit overkill, I think that it's a nice way to deal
> with multiple channels configurations while leaving total freedom… better
> than the approach of max msp, puredata or even analog equipment, where to
> have stereo chains one always needs to have a parallel, identical
> processing chain.
>
> >
> > it's the merger that does this. In your code, the merger has 2 inputs,
> but the number of output channels is the sum of the number of channels of
> the -- active -- inputs of the merger. input here means
>
> this was a typo btw... read "active here means"… that is you always to
> keep something connected to the inputs in order to know how many channels
> you have in the output.
> best
> alessandro
>
> > "connected to some source node", and it's consistent, since there is no
> way to know how many channels the input N has until some other node that
> provides an audio stream gets connected to it…
> > So, until you don't connect some other node to the second input (input
> 1), the output will remain mono, as long as your source node for the input
> 0 is mono.
> > To summarize, for a merger with 2 channels, the input/output
> configurations are:
> >
> > Input0          Input1          Output
> > Mono       -            Mono
> > Mono    Mono    Stereo
> > Stereo     -            Stereo
> > Stereo  Mono    3 channels
> > Stereo  Stereo  4 channels
> >
> > and so on… (and I sincerely hope this is correct)
> >
> > >
>
>