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.