Hi Spencer, I've prepared another LiSa patch. Besides fixing some bugs, its main objective is to allow loop points where start > end which is processed like the loop starts at loopStart, ends at the buffer end, wraps around and continues until loopEnd. Can be played with rate < 0 as well. In other words, this may be useful if the entire buffer is a loop and you would like to play a "sub" loop that wraps around the buffer edges. Also, it allows all durations (like loopStart/loopEnd) to be negative or larger than the buffer meaning duration from buffer end and duration from buffer start respectively. I find this useful for calculations but it breaks code like: lisa.duration() => lisa.loopEnd; Since duration() is actually greater than the last addressable byte in the buffer (which is at duration() - samp), so the expression sets loopEnd to the first byte in the buffer. Lines like the above would have to be changed into either: lisa.duration() - samp => lisa.loopEnd; or -1*samp => lisa.loopEnd; The last example reminded me that for no apparent reason ChucK doesn't do the unary minus on durations. I've attached another simple patch that fixes this. I'm still testing and playing around with it, but please let me know about your opinion regarding the general idea. Best regards, Robin On 12/09/12 12:07, Spencer Salazar wrote:
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
_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev