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

Robin Haberkorn robin.haberkorn at googlemail.com
Wed Sep 12 23:43:23 EDT 2012

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;
-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,

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 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
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lisa-wrapping-loops.patch
Type: text/x-patch
Size: 37877 bytes
Desc: not available
URL: <http://lists.cs.princeton.edu/pipermail/chuck-dev/attachments/20120913/ca6647ac/attachment-0001.bin>
-------------- next part --------------
commit 9e91551ae396a4ff01b44676a58b1b7ec964a62c
Author: Robin Haberkorn <robin.haberkorn at googlemail.com>
Date:   Wed Sep 12 22:58:07 2012 +0200

    allow unary minus on durations
    there is no reason why "-1*samp" should works but not "-samp"

diff --git a/chuck_emit.cpp b/chuck_emit.cpp
index b2f7a6c..512d048 100644
--- a/chuck_emit.cpp
+++ b/chuck_emit.cpp
@@ -2554,7 +2554,8 @@ t_CKBOOL emit_engine_emit_exp_unary( Chuck_Emitter * emit, a_Exp_Unary unary )
         // negate
         if( equals( unary->exp->type, &t_int ) )
             emit->append( new Chuck_Instr_Negate_int );
-        else if( equals( unary->exp->type, &t_float ) )
+        else if( equals( unary->exp->type, &t_float ) ||
+                 equals( unary->exp->type, &t_dur ) )
             emit->append( new Chuck_Instr_Negate_double );
diff --git a/chuck_type.cpp b/chuck_type.cpp
index 4f817b8..3b642d1 100644
--- a/chuck_type.cpp
+++ b/chuck_type.cpp
@@ -2041,8 +2041,8 @@ t_CKTYPE type_engine_check_exp_unary( Chuck_Env * env, a_Exp_Unary unary )
         case ae_op_minus:
-            // float
-            if( isa( t, &t_float ) ) return t;
+            // duration, float
+            if( isa( t, &t_dur ) || isa( t, &t_float ) ) return t;
         case ae_op_tilda:
         case ae_op_exclamation:
             // int

More information about the chuck-dev mailing list