Re: [chuck-users] LiSa .rate() issue (bug)

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): # .rate - ( float, WRITE ) - set playback rate (voice 0). Note that the int/float type for this method will determine whether the rate is being set (float, for voice 0) or read (int, for voice number) # .rate - ( int voice, float, WRITE ) - for particular voice (arg 1), set playback rate # .rate - ( READ ) - get playback rate (voice 0) # .rate - ( int voice, READ ) - for particular voice (arg 1), get playback rate. Note that the int/float type for this method will determine whether the rate is being set (float, for voice 0) or read (int, for voice number) dt On Nov 8, 2008, at 7:46 PM, Kassen wrote:

Dear list (especially Dan),

I just spend a hour or so pulling my hair out wondering why my little toy turntable wouldn't "scratch" anymore. It turns out that the issue is some changed behaviour in LiSa's .rate(). I believe .rate() no longer automatically casts integers to floats while previously it did. The following example demonstrates the issue;

//============8<================= LiSa l => dac; second => l.duration;

//just making sure <<>>;

//note this is a integer -1 => l.rate; <<>>;

-1.0 => l.rate; <<>>; //============8<=================

I'm not sure how this can happen as casting integers to floats is supposed to be automatic in ChucK. If somebody could please look into this?

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