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

Robin Haberkorn robin.haberkorn at googlemail.com
Sun Sep 9 08:53:20 EDT 2012


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
> 


More information about the chuck-dev mailing list