Re: [chuck-dev] Stereo ugens (again)

21 Feb 2007

      Hi Imre,

I'm not sure the solution you propose can easily be implemented for  
all UGs.  For a Noise UG, it is relatively easy to make it work for  
an arbitrary number of channels.  However, a SineWave UG is  
inherently "one channel".  Of course, you could hack something  
together but you would need to add a bunch of functionality to set  
the parameters for different channels, when in fact it would be much  
clearer (programatically) to have multiple instances of this one- 
channel class.  Perhaps ChucK can add functionality to easily combine  
the outputs of multiple one-channel objects into a multi-channel  
structure (or maybe this already exists)?

Also, for the Effects classes, it gets even more problematic.  If you  
want to make a Reverb work for multiple channels, does that mean it  
should take a single input and create multiple outputs or should it  
run multiple versions of the same reverb to create multiple outputs.   
The number of inputs and outputs to the Effects classes are typically  
fixed when it they are designed and it would be hard to make them  
work for arbitrary inputs/outputs.  I suppose that a Reverb could  
average a multi-channel input sample frame and create as many  
decorrelation delay lines as needed for the specified number of  
outputs, but again, these are things that would have to be determined  
for each Effect.  For the PitShift class, it is unclear how mulit- 
input/output might be implemented.

Regards,

--gary

On 11-Feb-07, at 10:23 AM, Imre Kéri wrote:
...
Hi Gary,
My idea is now the following: Every UGen should work for any number of
input/output channels. When the user creates an UGen, the number of
requested in/out channels for that UGen need to be specified by the
user. The tick() function should then accept/generate the requested
in/out channels. Once the UGen is created, it can be ChucKed to any
other UGen (also to those with different number of channels - or
not??). And each particular channel should be also accessible.
For STK this can mean that for example the constructor of the Effect
class should have two new parameters: the number of in and out
channels. The tick() or tickFrame() function should get as parameter
the incoming frames (one sample for each input channel) and compute
one (or more) sample for each output channel.
Every effect and instrument should find a meaningful implementation
what to do when the user requests it to work on N channels (or it
might refuse some channel combinations?). A noise generator might
compute only one mono sample of noise and simply copy it to every
output channel, or it might generate separate noise for each channel.
A reverb can use a different algorithm if requested for 2 channels
than it uses when requested for 1 channel.
This may require some changes in the existing code, but I like this
solution beause it seems very flexible... In ChucK it would be even
possible to have a new syntax for the requested number of channels and
compile-time checking for channel stuff...
Imre
2007/2/10, Gary Scavone :
...
Hi Imre,
This is an issue in STK as well.  I don't know the exact details of
how STK classes are incorporated into ChucK (hopefully without any
changes?) but I would like to find an elegant solution to this issue
that works both in STK and ChucK.
First, there is something I'm not clear on in your email.  Let's take
a Noise UGen as an example.  As it stands, the Noise class is
inherently monophonic.  If you want multi-channel Noise, you could
simply create multiple instances of it.  But perhaps you are asking
that it be changed to support an arbitrary number of channels (which
would probably be more efficient than creating multiple instances)?.
In STK, you can pass an StkFrames object to the tick() function and
it will fill that structure with the appropriate number of samples
(given the number of sample frames of the StkFrames). However, as
currently written, it only fills one channel of the StkFrames
object.  It would be easy to modify that behavior if desired.
The next question concerns UGens that could truly be multi-channel.
For example, reverberators tend to support one sample input and
stereo output.  The Effect class has lastOutRight() and lastOutLeft()
function to support stereo though the tick() function itself only
outputs mono data.  I consider this somewhat broken.  I'd like to
come up with a better generic solution to this problem.  One
potential solution can be taken from the WvIn/WvOut classes, which
have a tickFrame() function that does support arbitrary multi-channel
input/output.  However, that structure does not make it clear how
many channels are supported by a given class.  Also, I've heard from
others that they would like a tick() like function that supports
multiple channels and does not require the use of an StkFrames
object.  I suppose we could potentially create a tickChannel()
function that takes a channel argument(?).
I'd be happy to hear if others have ideas about how best to address
these issues.
Regards,
--Gary Scavone

chuck-dev mailing list
chuck-dev@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev