- chuck-users - lists.cs.princeton.edu

Re: [chuck-users] negative duration syntax and bug
by Les Hall 14 Nov '08

14 Nov '08

Press Release: In a startling discovery made earlier today by musician and self-described ChucKist "Kassen", it was revealed that negative time actually exists. Long theorized by science fiction authors and audiences, the discovery has baffled modern scientists. When questioned, the mysterious "Kassen" was unavailable for comment because he had travelled back in time to enjoy last weekend's party one more time. It is, however, suggested by other ChucKists that the time reversal phenomenon exists only in the mind of ChucK and is in fact a bug. Presumably a bug that flies backward, but that, again, is pure speculation. In fact, the whole concept of negative time in a ChucKian universe may actually be a very carefully planned practical joke created by the ChucK Dev team in the future of the past which is actually now. This has been an up-to-the-minute report (so to speak). Les (Inventor)

3 3

negative duration syntax and bug
by Kassen 12 Nov '08

12 Nov '08

Fellow ChucKists, This is runs; <<<-1 * second>>>; Hence we know that negative durations are fine. This, on the other hand causes a problem; <<<-1::second>>>; We can get around that by using this; <<<(-1)::second>>>; That one does run but it also seems very clumsy to me. I'm getting the impression that for durations expressed like -3::second the minus sign somehow isn't a part of the number while elsewhere it is. This doesn't strike me as very coherent. While I was testing some other things around negative durations I noticed that this will crash with seg-fault; second -=> now; Admittedly it would be a type of expression that would only be useful with negative durations... Probably quite rare but it shouldn't crash the whole VM like that. Yours, Kas.

1 0

array declaration bug
by eduard aylon 11 Nov '08

11 Nov '08

Hello list, I found out that declaring arrays in this way: float a[], b[]; is buggy, as it seems the type for b[] is not taken as float. Maybe something else happens here (maybe passing by ref), I haven't check thoroughly (don't know if it happens with other types as well). See the following code: // ******************************* // this works: // ******************************* float freq, amp; fun void Do( float freq, float amp) { <<<"do sthg">>>; } Do(freq,amp); // ******************************* // also works: arrays declared in separate lines // ******************************* float freq1[1]; float amp1[1]; fun void Do( float freq[], float amp[]) { <<<"do sthg">>>; } Do(freq1,amp1); // ******************************* // throws error :argument type(s) do not match // arrays declared in the same line // ******************************* float freq2[1], amp2[1]; Do(freq2,amp2);

2 2

dangerous games with shreds
by eduard aylon 11 Nov '08

11 Nov '08

Sorry list for bombing you with so many questions, but got this funny one, which I thought would be interesting to post. The patch below loops endlessly although no while(true) loop exists in the "main". If you try the patch, be warn that your computer may (or may not) become unresponsive. The code makes sense, and the behaviour as well, but should chuck throw a warning when something like this happens? I came up with this, while trying to have a process for reading and another for writing, but didn't want to advance time in any of them. eduard class mySpork { Event write; Event read; fun void start(){ read.signal(); <<<"started">>>; } fun void Write() { // NOTE: time is not advanced in this function while(true) { write => now; //<<< "writing" >>>; read.signal(); } } fun void Read() { // NOTE: time is not advanced in this function while(true) { read => now; //<<< "reading" >>>; write.signal(); } } } mySpork myspork; spork~myspork.Read(); spork~myspork.Write(); me.yield(); myspork.start(); <<< "loops forever">>>; 1::second => now; <<< "and never gets here">>>;

4 5

64-bit chuck
by Roger Critchlow 10 Nov '08

10 Nov '08

Greetings Chuckists -- This looks like a lot of fun, but I have one axe to grind. I see that the question of 64-bit chuck came up on the mailing list 2 years ago and after reviewing the code I can see why nothing has happened since. It's a little unfriendly to be so coy about this. You're very careful to discourage Mac and Windows users from attempting to recompile from sources. But someone who's trying to compile on a 64-bit operating system gets no warnings, no cautions, no under construction signs, nothing from the download and build web pages to indicate any problems at all. If you look through the information files of the downloaded sources for indications of 64-bit problems, you find: VERSIONS: - corrected more issues on some 64-bit systems VERSIONS: - corrected issues on some 64-bit systems Until you get around to fixing it, could you at least mention somewhere on the web pages or in the information files that your code truncates 64 bit pointers to 32 bits before dereferencing them so we can stop figuring it out the hard way? Please? Thanks, -- rec --

1 0

yet another lisa bug?
by eduard aylon 09 Nov '08

09 Nov '08

Hi Dan and others, I don't think this is the expected behaviour for lisa: when duration is set, the number of maxVoices is reset to 10, the default. Please, check attached patch. eduard LiSa lisa; lisa.maxVoices(100); <<<lisa.maxVoices()>>>; lisa.duration( 1::second); <<<lisa.maxVoices()>>>;

2 2

division by zero bug
by eduard aylon 09 Nov '08

09 Nov '08

Hi, the following code does not crash nor throw any exceptions: 0 => float z; 2::second => dur n; n/z => dur k; // division by zero!! while(true) { k => now; } althought it does throw a floating point exception when types are ints, it doesn't when types are floats or time based. Well, at least on my system: OS X Leopard. eduard

1 0

MiniAudicle CVS (Mac OS X)
by Juan-Pablo Caceres 09 Nov '08

09 Nov '08

Hi everyone, Which is the latest stable CVS (or SVN) of miniAudicle/Chuck for OS X? I didn't have luck googling (sorry if this has been asked before). The latest release of miniAudicle is version 0.1.3.9 (with ChucK: version 1.2.1.2 (dracula)) Both are fairly old (more that a year as far as I can tell), so I'd love to get the latest version. Thanks! Juan-Pablo

2 3

LiSa .rate() issue (bug)
by Kassen 09 Nov '08

09 Nov '08

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 <<<l.rate(), " default rate">>>; //note this is a integer -1 => l.rate; <<<l.rate(), " should be -1 but isn't">>>; -1.0 => l.rate; <<<l.rate(), " should be -1">>>; //============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.

3 7

help understanding lisa
by eduard aylon 06 Nov '08

06 Nov '08

Hello list, I am trying to build a granular patch with lisa, but for some reason I am getting clicks every time lisa repeats the buffer. Maybe it has to do with lisa's duration? Hope someone can explain me what I am doing wrong. Following I attach two examples one uses lisa the other uses an array. The one that runs with lisa has clicks, the other sounds pristine, why? (even if rampup and rampdown were set for lisa). The strange thing is that if recorded to file and checked with an audio editor I can't see any strange artifacts in the waveform. thanks for any help, eduard // the patch that uses lisa: LiSa lisa => dac; 1024 => int size; size::samp => lisa.duration; for (int i; i < size; i++) { lisa.valueAt(Math.sin(2.0*pi*60*i/size), i::samp); } 1 => lisa.play; while(true) { lisa.rampUp(10::samp); lisa.duration() - 20::samp => now; lisa.rampDown(10::samp); } // the other patch with a simple buffer: Impulse imp => dac; 1024 => int size; float buffer[size]; size - 1 => int bitmask; for (int i; i < size; i++) { Math.sin(2.0*pi*60*i/size) => buffer[i]; } 0 => int pos; while(true) { buffer[pos&bitmask] => imp.next; pos++; 1::samp => now; }

6 18