[chuck-dev] Stereo ugens (again)
sharp732 at gmail.com
Sun Feb 11 13:23:38 EST 2007
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...
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.
> --Gary Scavone
More information about the chuck-dev