[chuck-dev] Stereo ugens (again)

[Imre Kéri]

Hi!

As I though of it, e.g. an oscillator would just output the same
signal on every output channel (and not have varying parameters for
each channel). And for other effects, it should be decided at desig
time how to implement the functionality when a user is requesting it
for multiple channels. It could just run as multiple instances of it
on all channels, or it could use different algorithms - so when the
user is creating a mono and a stereo instance these will act as two
totally different effects.

But I realized now that though the idea would be nice in some
situations (like SndBuf), in general it doesn't bring much benefit to
have it. For the developer it is much easier to write for example a
mono and a stereo reverb than to combine these into a single object.
And this is also not more problematic for the user than my original
idea (just with my idea it would be easier to change the number of
channels for an UGen?)

So I drop this idea. But what would be still nice to have is support
for real multi-channel UGens in ChucK. As it is now there is some
multichannel support but only panning works and the tick() function is
always mono. Every instrument/effect should have a fixed number of
input/output channels and the tick() function (or multiple
tick_channel() functions?) should be called by the framework
accordingly.

Regards,
   Imre

2007/2/22, Gary Scavone <gary at music.mcgill.ca>:
> 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 <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
>
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
>