Greetings! I second Kassen and would like to say rock on to your chuckian coding rampage so far!

...

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".

I think putting when/by-whom a change is introduced inline in the code tends to naturally improve the information about context and intention, and in ways that outside-of-code things like 'git blame' doesn't do (and yet it doesn't undermine 'git blame' -- one can still do that as per usual). It's meant to be additive to the usual good practices (e.g., proper commit messages), not a substitute. Now, I don't claim this is good or bad practice, but it seems useful for chuck, and that's why we've chosen to do this. Thanks again for your efforts! Ge!

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

Hi Kassen, hope I can clarify some of my motivations. On 13/09/12 06:22, Kassen wrote:

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.

The line only worked previously because the value you give as loopEnd() was automatically clipped to duration()-samp. Only loopEnd() was clipped. On loopStart() you could specify arbitrarily large values, likely crashing your VM... The idea was to standardize how buffer positions are checked/processed. Negative values are allowed so you can do calculations like this: lisa.loopEnd() - second => lisa.loopStart; and it will always mean 1 second before loopEnd, even if that duration is negative. E.g. if duration() == 2::second and loopEnd() == 500::ms, loopEnd() - second == -500::ms was previously clipped to 0::samp when setting it as loopStart(), so you only actually got a 500::ms loop. Of course loopStart() had to be smaller than loopEnd(). If you had set it larger, this effectively crashed your VM!!! Now when using -500::ms => lisa.loopStart(), -500::ms is translated to a position "from the right edge of the circular buffer", i.e. to 2::second - 500::ms == 1.5::second. When you query lisa.loopStart() afterwards you will get loopStart() == 1.5::second. IMHO, allowing negative values is not that unintuitive. Popular programming languages like Python interpret negative array indices in a similar manner (this was taken from the Icon programming language...). And yes, I also don't like that these changes break existing code. That's why I asked for your opinion. Luckily the index-normalization stuff can be separated from the looping-changes. Perhaps it's best to "normalize" all durations uniformly by clipping to [0::samp, duration()-samp] and if you want to do calculations like the above you can still do them on your own (in ChucK code)... lisa.loopEnd() - second => dur start; if (start < 0::samp) lisa.duration() +=> start; start => lisa.loopStart(); ...which is not quite as powerful as my patch' normalization, but it will work for this example. We could also add the "normalization" which is nevertheless required for the internal getNextSamp() method, as a LiSa member function, so you could write: lisa.loopEnd() - second => lisa.normalize => lisa.loopStart; Sounds like a good compromise, doesn't it? Even if you don't like that I could live with it since I can still add that method to my own LiSa derivation (written in ChucK). If you agree I'll adapt my patch accordingly.

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).

I think you misunderstood. LiSa already worked that way: 2::samp => lisa.duration() meant you got 2 samples of data in your buffer, with valid positions (e.g. for loopStart/loopEnd) 0::samp and 1::samp, in other words 0::samp to duration()-samp. My patch doesn't change that. The only change regarding buffer positions is (or should be) that when setting parameters like loopStart, they are *normalized* to values/durations between 0::samp and duration()-samp *before* setting them and returning the normalized values.

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

The patch indeed introduces a little bit of overhead, even though the looping/non-looping checks were (necessarily) already there, there is now another check for the nature of looping. If loopStart > loopEnd, a few more calculations and logic is required because of the possible looping over the buffer end. On the other hand I think I optimized a little bit, e.g. by caching the loop length which is required multiple times in tick/tickf at sample rate but changes very infrequently (only if loopStart(), loopEnd() or duration() changes). I also cleaned up the code, at least where I touched it so it should be more readable now if you would like to have a look.

Erm... Dan? :-)

Kas.

What about the unary-minus-durations.ck (it's a patch, I accidentally named it .ck)? It's a very simple change that seems consistent to me. Best regards, robin

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

On Thu, Sep 13, 2012 at 05:39:51PM +0200, Robin Haberkorn wrote:

Hi Kassen,

Hey Robin!

hope I can clarify some of my motivations.

Yes, let's go over it but let me first clarify that it was just the "-1" that I disliked and that I love the work you are doing. I think I sounded a bit harsher than I meant to.

The line only worked previously because the value you give as loopEnd() was automatically clipped to duration()-samp. Only loopEnd() was clipped. On loopStart() you could specify arbitrarily large values, likely crashing your VM... The idea was to standardize how buffer positions are checked/processed.

I do seem to remember we previously had a LiSa issue with loops being off by 1 sample under some conditions. Dan fixed that. So; right now we at least have a fix to this loopStart() issue, that is nice.

IMHO, allowing negative values is not that unintuitive. Popular programming languages like Python interpret negative array indices in a similar manner (this was taken from the Icon programming language...).

Yes, there I agree, even values beyond the end would arguably make sense, in that a "loop" is really a bit like a infinitely long (if monotonous) recording. So far we still agree.

And yes, I also don't like that these changes break existing code. That's why I asked for your opinion. Luckily the index-normalization stuff can be separated from the looping-changes. Perhaps it's best to "normalize" all durations uniformly by clipping to [0::samp, duration()-samp] and if you want to do calculations like the above you can still do them on your own (in ChucK code)...

lisa.loopEnd() - second => dur start; if (start < 0::samp) lisa.duration() +=> start; start => lisa.loopStart();

...which is not quite as powerful as my patch' normalization, but it will work for this example. We could also add the "normalization" which is nevertheless required for the internal getNextSamp() method, as a LiSa member function, so you could write:

lisa.loopEnd() - second => lisa.normalize => lisa.loopStart;

Sounds like a good compromise, doesn't it? Even if you don't like that I could live with it since I can still add that method to my own LiSa derivation (written in ChucK). If you agree I'll adapt my patch accordingly.

This example looks a lot better to me, without the arbitrary "samp" in it. If I have a duration called "beat" then I want to be able to poll LiSa for the current loopStart() add a beat to it, set loopEnd() to the result and then I want the result to always be a loop to exactly 1::beat. Maybe I misread your post, but where I balked was the implication that we had to subtract a sample, sometimes, to get the correct loop length.

I think you misunderstood. LiSa already worked that way: 2::samp => lisa.duration() meant you got 2 samples of data in your buffer, with valid positions (e.g. for loopStart/loopEnd) 0::samp and 1::samp, in other words 0::samp to duration()-samp. My patch doesn't change that. The only change regarding buffer positions is (or should be) that when setting parameters like loopStart, they are *normalized* to values/durations between 0::samp and duration()-samp *before* setting them and returning the normalized values.

I think we are "in tune" again. Would I be correct to say that LiSa was "cheating" to enable us to do what I wrote above, that you extension exposed that and that we now have to deal with this? Mind you; I quite like your take. I I would do the above I would currently need to check that loopStart+beat was smaller than the end of the buffer. With your take that would no longer be needed and the result would make sense; we'd just wrap. I like that a lot.

The patch indeed introduces a little bit of overhead, even though the looping/non-looping checks were (necessarily) already there, there is now another check for the nature of looping. If loopStart > loopEnd, a few more calculations and logic is required because of the possible looping over the buffer end. On the other hand I think I optimized a little bit, e.g. by caching the loop length which is required multiple times in tick/tickf at sample rate but changes very infrequently (only if loopStart(), loopEnd() or duration() changes). I also cleaned up the code, at least where I touched it so it should be more readable now if you would like to have a look.

That we will survive, I was hoping to somehow simplify it all until things became simple and "obvious". Maybe the problem is simply hard.

What about the unary-minus-durations.ck (it's a patch, I accidentally named it .ck)? It's a very simple change that seems consistent to me.

I'm going to have a look. Still need to build and install the latest greatest. I hope Dan will chime in here and that we can have your improvements while keeping the nice "straightforward" reasoning about time and loops. IMHO ChucK's syntax is there to make us type in things as they appear to us with as little "adapting to the underlying system" as possible. Thanks for the clarifications and sorry again that I sounded a bit harsh going from "I like this" to "I don't like that". Yours, Kas.

On 17/10/12 15:58, Kassen wrote:

On Sat, Sep 08, 2012 at 11:50:11PM +0200, Robin Haberkorn wrote:

...

Hi!

Hey Robin!

...

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'd like to test your fixes this evening.

Could you tell me what/where is the most up to date version? Another question; I can ask, maybe I get lucky; would there be a way to separately test the bug fixes and the new things you came up with for the current state of your work?

I've attached all three of the patches I previously submitted in this thread. Based on chuck-v1.3.1.2 (same version I use). Regarding your second question: No unfortunately you can't since I was not disciplined enough to separate them. I started to work on it in order to improve LiSa performance and add features and ended up rewriting part of LiSa and fixing a lot of bugs in the process. I could spend some time to rewrite all of the changes though... btw. I wasn't active on the list for the last few weeks since I worked on a kind of 2d graphics package that may be used with ChucK. Indeed I wrote it to use it with ChucK and it contains ChucK wrappers: github.com/rhaberkorn/osc-graphics Hope to announce it soon on the ChucK mailing list. cheers, robin

Thanks, Kas.

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev