[chuck-dev] LiSa revised - fixed many bugs (PATCH)

[Spencer Salazar]

Hey Robin,

I haven't had a chance to thoroughly review your patch, but to answer your
questions --

tickf provides an input and output buffer within which nframes frames are
allocated for, each consisting of a sample for each channel. I forget if
different numbers of input/output channels are handled correctly, so if
weird things are happening that could be an issue. But
basically buffer[i*nc+c] will hold the sample for channel c of the i-th
frame, assuming there are nc total channels.

You should be able to derive from UGen, change the number of channels, and
use either a tick or tickf function (but never both) -- see WvOut2 or
SndBuf2 for an example.

nframes can be > 1 if you have --adaptive# set (experimental adaptive
sample block buffering).

Changing the number of I/O channels in a ugen at run-time definitely seems
the most natural mode of operation, but poses some problems in terms of the
details of that operation. For example, what happens to existing
connections the ChucK programmer has made between individual ugen channels.
I don't mean to open up a discussion about such issues, but rather to give
an idea of what challenges are involved in the "ideal" approach. Truthfully
there seem to be enough pitfalls with changing the number of IO channels at
run time that Im not sure the benefits justify the few use cases Im aware
of.

spencer


On Sun, Sep 9, 2012 at 2:53 PM, Robin Haberkorn <
robin.haberkorn at googlemail.com> wrote:

> I'm not yet a ChucK expert. Did I do the multi-channel UGen stuff
> correctly (tickf)?
> Exactly how does tickf work? When do I get nframes > 1?
> Also, is it really necessary to have a tick-function when building the
> UGen as mono? I found that setting the UGen up as UGen_Stereo/Multi but
> specifying only one output channel does not work. Neither can I derive
> the class from "UGen" but specify only a tickf-function - for some
> reason I need the "tick" function. When deriving from UGen_Stereo, I
> must specify a tickf-function for multichannel output to work, but I may
> also specify a tick-function. Is it ignored?
>
> It would seem plausible to be able to derive from UGen_Multi but specify
> only one output channel (it's just a special case). Also it would seem
> useful and clean to be able to change the number of in/out channels at
> runtime, e.g. so a SndBuf always has as many output channels as the
> loaded soundfile. Instead you have introduced new classes (e.g. SndBuf2
> which is derived from SndBuf but has 2 output channels).
>
> What do you think?
>
> On 08/09/12 23:50, Robin Haberkorn wrote:
> > Hi!
> >
> > As promised I took a look at LiSa and fixed many bugs. See the git
> > commit description in the patch for details. It applies to v1.3.1.0.
> >
> > I couldn't really improve its performance significantly but you may now
> > again compile LiSa as a mono UGen (#define LiSa_channels 1) which does
> > the trick for me. Haven't yet even used a profiler or memory checker on
> > ChucK (but I will sooner or later).
> >
> > Tested LiSa only superficially but some things like tracking mode 1 and
> > 2 are completely broken beginning with v1.3.0.0! Will test them soon and
> > post updated patches if necessary as I intend to use these tracking
> modes.
> >
> > btw. I see many examples in the ChucK code where comments are used to
> > denote author and subject of a change. Why are you doing that? If every
> > developer writes proper commit messages you may just as well use "svn
> > blame" (or later "git blame") and "svn log".
> >
> > Best regards,
> > Robin
> >
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-dev/attachments/20120912/fc78077a/attachment.html>