[chuck-dev] Stereo ugens (again)

Gary Scavone gary at music.mcgill.ca
Wed Feb 21 20:40:58 EST 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.



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 <gary at music.mcgill.ca>:
>> 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

More information about the chuck-dev mailing list