yeah, i can reproduce it. i tried it with SndBuf to see if it has the same problem, which it doesn't, so then i compared the source code, and the only difference is that SndBuf uses GET_CK_FLOAT(ARGS) to get the float, whereas LiSa uses GET_NEXT_FLOAT(ARGS). i'd rather find out from Ge what the issues are before trying to fix this by using GET_CK instead of GET_NEXT, cause i don't know what else might break in the meantime.... thanks for tracking this down, dt On Nov 9, 2008, at 8:48 AM, Kassen wrote:

2008/11/9 dan trueman a mystery to me as well!

But you can reproduce it, right? I saw the same thing happen on the latest plain Linux version and on the ASIO build Steve did.

At least if you find it mysterious as well I won't have to feel as bad about hunting for this for so long. I was starting to imagine .playPos() was resetting the rate now and things like that.

Yours, Kas.

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

2008/11/9 dan trueman

ok, i think i've figured this out. it's because of function overloading. when you call rate(1), it RETURNS the rate for voice 1. when you call rate(1.), it SETS the rate for voice 0 to 1. this is specified in the online doc (but i'd forgotten about it):

Ok, that makes sense but this must've changed in the last version of ChucK because previously my code did work as I intended it. I think it's a good change, BTW, it solves that question quite nicely, I like it. You know I'm a big fan of your work on LiSa but I'd still like to say I'd appreciate it if changes like this could go in the VERSIONS text that keeps track of changes. I feel bad to critique while you spend so much hard work on LiSa but this was a bit confusing. Right, on to the future. In the same session I wondered whether it would be possible to detect whether a specific voice was playing. I don't think we can right now. Maybe the command to make a voice play should also be a float and if it's non-zero start playback while also using the value to set .voiceGain()? that way we could use .play(int voice) to get a 0 or 1 to indicate whether the voice is currently playing. Oh... and the bi directional looping is another one that takes a int for it's parameter. I'm not sure what to do there. Yours, Kas.

Dan; that sure would be good! but i'm just not that organized. i'll try... and i

appreciate the critique so no worries there.

I can certainly identify with that :¬). Maybe we can blame Ge? Blaming Ge always works out well. What if we'd say Ge is The Great Keeper Of ChucK and should be held accountable for making the VERSIONS text line up with the commits that get used? I'm only half joking, it does make sense to me that there should be a strong link between what goes in and the documentation of what went in. alternatively, we could have .playing(int voice) which returns the 0 or

1....

Sold. if (my_lisa.playing(3) ) do.something(); looks good to me.

could just have .getbi(int voice). (cute name).

I'm in favour of this. Everybody loves LiSa so maybe LiSa should love everybody back. :¬)

i don't think overloading this makes sense, since it's a boolean and we don't want that to be a float.

I agree, and I couldn't see any useful application for a float there, with .play() at least a float could make sense, like it does with the STK instruments .noteOn(). I quite liked the voice-pan plans I saw in the source as well. This is becoming quite a monster UGen. Yours, Kas.