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