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@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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev