2. Uncomment 3 lines in the ChucK makefile you are using (makefile.alsa, makefile.oss, or makefile.jack) at this point: ... Sorry for this massive hack!

Hm.. It was very easy :-) But I didn't guess to look in makefile. "$ chuck otf_0?.ck" sounds very cool :-) I think you may to switch on this option for Linux by default - I think there are not Linux distributions without libsndfile.

(int)(open.length/1::samp) => int tlen;

// a few lines below (int)(closed.length/1::samp) => int tmplen;

Yes, it works! :-D

Please let us know if you run into more problems.

It is not big trouble but if I try to use more than 4 channels likely: BeeThree a => dac; BeeThree b => dac; BeeThree c => dac; BeeThree d => dac; BeeThree e => dac; then I get very bad sound :-( Maybe there are way to solve this? Very BIG Thanks! -- registered Linux user #360474 Don't worry, I can read OpenOffice.org

...

...

Please let us know if you run into more problems.

It is not big trouble but if I try to use more than 4 channels likely: BeeThree a => dac; BeeThree b => dac; BeeThree c => dac; BeeThree d => dac; BeeThree e => dac;

then I get very bad sound :-( Maybe there are way to solve this?

As Adam pointed out, the ugen's maybe be using too much resource. This is possible but unlikely in this case, since BeeThree's aren't that CPU intensive (BeeThree use FM). Another possibility is that you are clipping at the dac because you are summing too many inputs. In fact, a quick experiment clips at 5 BeeThree. If that is indeed the problem, then it's easy to a) simply change the gain at the dac (not recommended, since dac is global) or... b) sum the BeeThree channels into a gain, and control the gain at that point (recommended): // sum into gain BeeThree a => gain g => dac; BeeThree b => g; BeeThree c => g; BeeThree d => g; BeeThree e => g; // change the gain at g .2 => g.gain; // ... Hope this helps. Best, Ge!

...

...

...

...

"GW" == Ge Wang writes:

...

2) With many programs from http://wiki.cs.princeton.edu/index.php/ChucK_Programs I got errors like [hihat.ck]:line(38): cannot cast to type 'int' from 'dur'...

GW> I got the same error on hihat.ck. This is due to a recent change in GW> the sndbuf API (sorry) where length is a 'dur' and no longer a 'int'. GW> I think the way to fix this is by dividing the duration by the GW> appropriate unit (samp, the duration of a sample in this case). GW> (Gary, please let me know if my changes are incorrect.) GW> (int)(open.length/1::samp) => int tlen; Yes. But there should be no need for a temporary variable at all, here's what's in http://www.stacken.kth.se/~kaj/2005/chuck12.en which it came from: "data/hihat-open.wav" => open.read; (int)(open.length/1::samp) => open.pos; ... apparently, I'd written that with a (yet unreleased) development version. :-) Also, as you, Ge, says on the Wiki, you can set 0.0 => open.rate, but then you will have to both reset the position and the rate when (re)starting the sample, I found those two operations rather than one to clobber the source ... -- Rasmus Kaj --+-- rasmus@kaj.se --+-- http://www.stacken.kth.se/~kaj/ I do not fear computers. I fear the lack of them. -Isaac Asimov