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

[Kassen]

On Thu, Sep 13, 2012 at 05:43:23AM +0200, Robin Haberkorn wrote:
> 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.
> 

I like this. I like it better than reversing under such conditions,
which can also be done with a negative rate. It seems consistent with
LiSa's "loopy" nature.

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

Sorry, but I don't like this at all. I don't like it breaking that
line which I suspect to be very common in LiSa-using code and I don't
see the logic. IMHO this "-1" isn't beautiful or self-evident. 

If we simplify it all to a 2::samp buffer then the
issue becomes clear; we have 3 values. What if we would make the end
value (the 3rd, as programmers we call it "2") identical to the value
at 0? When looping that causes no new issues. It also causes no issues
that were not there anyway when not looping; if that would cause
discontinuities  then you had non-0 points at the beginning or end
anyway (or at least a non-identical beginning and end).

That would clear out this "-1" and it sounds like looping over a
n::samp buffer would take (n+1)::samp of time with your plan (correct
me if wrong) which will cause issues when dealing with guitarists
and/or drummers.

With your solution I could make a square wave with duration/period of
1::samp (actually taking 2). With all due respect to your work that
seems a bit silly to me. On the other hand; I'm open to my own
suggestion here potentially causing more glitches in edge-cases like a
LiSa used as a CV-signal ramp; we can't tell people to use SndBuf
there as SndBuf can't be set procedurally as LiSa can, I think. 

Checks for looping or non-looping behaviour on the other hand add more
complexity to LiSa herself and hardly will win any beauty awards
either....

Erm... Dan? :-)

Kas.