Ok, I tried it.

Me too!

It compiled without problems, but the test example doesn't output any sound. There's no error from pd. The chuck~ object seems to load properly (setting vars and printing them works).

Worked well for me... got some noise, and some processed voice recording being routed through a chuck's delay effect.

I also tried with one of my chuck files. No output.

I tried some more complex ones without much success, but I tried a simple one with a single SinOsc and it worked. The strange thing was that it only worked the first time I sent the "add" message for that file. Subsequent times there was no output. I put a string dump at the beginning of my "test.ck": opening: /home/ssteve/.local/lib/pd/extra/chuck.so Chuck Main: chuck~.c (266) Finished DSP initialization: chuck~.c (273) [chuck](VM): sporking incoming shred: 1 (test.ck)... "here test" : (string) [chuck](VM): sporking incoming shred: 1 (test.ck)... [chuck](VM): sporking incoming shred: 2 (test.ck)... [chuck](VM): sporking incoming shred: 3 (test.ck)... [chuck](VM): sporking incoming shred: 4 (test.ck)... pd_gui: pd process exited So you see, after the first time, the chuck file never actually runs, although it is loaded.

Another thing that might interest you is that pd crashes when closing the window.

This also happened to me. Ubuntu Feisty here. I am trying to get a stack trace but for some reason Pd is not running very well under gdb. (never tried it before..)

I'm on linux (Slackware with a custom kernel). Pd has been built recently from CVS.

I'm also using a CVS version. This has great potential! Although in some ways I prefer to run chuck in a separate process and use OSC for communication, there are definitely advantages to this approach -> currently, it's easier to control chuck variables than defining OSC events for everything in chuck (i find this a little cumbersome in chuck), and also you can get the audio back into Pd and do further processing, which is a pretty awesome. ! Steve

Do you mind sending over a copy of the ChucK files that failed to work? From your experience with PD CVS, it seems there is definitely some changes to make for this.

Here's the "test.ck" file: <<<"here test">>>; SinOsc s => dac; 150 => s.freq; 1::second => now; The "more complicated" example was actually across a couple of files. I've been building a little library of drum-machine synths. I started with this "kick.ck" file I have: public class Kick { 300.0 => float freq; 0.0 => float endfreq; 1.0 => float gain; 300::ms => dur length; 3000.0 => float drop; /// TODO fun void play() { <<<"here">>>; SinOsc s => dac; freq => s.freq; // Ramp up for 1 ms now => time begin; now + 1::ms => time end; while (now < end) { (now - begin) / 1::ms * gain => s.gain; 1::samp => now; } // Play w/ decending frequency now + length - 1::ms => end; while (now < end) { 1::samp => now; s.freq() - ((s.freq() - endfreq)/drop) => s.freq; (end - now) / length * gain => s.gain; } } fun void trigger() { spork ~ play(); } } I found that if I put the following after this class definition: Kick k; k.play(); It works. However, this can only play it once. The idea is to have the Kick class available to more complicated scripts (i.e., sequences), but when I tried the above two lines in a separate file, "kicktest.ck", it didn't play. (That is, I click the message "add kick.ck" and then "add kicktest.ck" and it didn't play anything.) Maybe it's related to the other problem of not starting other chuck scripts after the first one.

Thanks for trying chuck~ out!

No problem! Steve

Seems that I forgot to keep the VM from halting while porting to the 1.2.0.7 release of ChucK. I've made a few changes that should fix most of the problems that you've been seeing.

Yes, this fixed it for me! Also, it no longer crashed when I closed the patch window. Great! Going to have fun with this... Cheers, Steve

On 3/12/07, martin robinson wrote:

On 3/12/07, Cesare Marilungo wrote:

...

Ok, I tried it.

It compiled without problems, but the test example doesn't output any sound. There's no error from pd. The chuck~ object seems to load properly (setting vars and printing them works).

Whoops. I misread this! I'm not sure why you'd get no output on a simple ChucK file. Do you mind trying a simple SinOSC script? -- martin robinson

martin robinson wrote:

...

It compiled without problems, but the test example doesn't output any sound. There's no error from pd. The chuck~ object seems to load properly (setting vars and printing them works).

...

I also tried with one of my chuck files. No output.

Is there any output on the system console? Some debugging information doesn't yet make it to PD terminal. It could be that you need to use the full path to the script you want to shred. Oh, & here is the latest version of the software:

http://www-static.cc.gatech.edu/ugrads/m/mjr/chuck~-0.1.1.tar.gz

Ok, this seems to work better, but I got to use the full path of the chuck file. Everyone loves chuck tilde! Keep up with the good work. Ciao, c. -- http://www.cesaremarilungo.com

Quoting Steffen :

How does one use the input vars in a chuck script? The pd_io.ck file didn't help me much. Maybe i'm thick. But i just wanted to control the frequency of a sine oscillator, but no luck with:

Pd io; SinOsc s => dac; io.get("abc") => s.freq; 2::second => now;

This is the same plea I was having for max/msp [chuck~]-- I would really like it if there was some way of writing a polling or notifying ugen that would allow dynamic 'external' entry for a parsed and executing chuck~ script. I don't think that the OSC or other net models currently in chuck will work, because they assume that the script is in process of being evaluated. The chuck~ objects parse the script and then call the chuck VM to run it -- at that point it seems that the initial values in the script are fixed, but maybe I'm missing something? brad http://music.columbia.edu/~brad

Quoting martin robinson :

Perhaps I'm misunderstanding something here, but each time you call io.get(...) it should return the latest value delivered to the chuck~ inlet. You might want to consider making a shred with a test loop to get a more real-time behavior.

while (100::ms => now) { io.get("abc) = s.freq; }

You might want to double-check this. I tried a similar thing with the max/msp chuck~, and discovered that the new values were not being delivered into the executing VM. Your code is probably better, though, so I should check it out and adjust accordingly! brad http://music.columbia.edu/~brad

Yes it clears, but I don't have much luck. The below script of cause work, and makes Pd play a 300Hz sine wave via ChuCK. If i uncomment the two comments and in stead comment out the '300 => s.freq;' line, it don't make any sound. If i instead only uncomment the first line, there is still no sound, hence it might have to to with the Pd UGen?

Wow! It looks like I forgot another line when porting to the latest ChucK release. In any case it should work now: http://www-static.cc.gatech.edu/ugrads/m/mjr/chuck~-0.1.2.tar.gz Hope this helps, martin robinson

Ok, this seems to work better, but I got to use the full path of the chuck file.

I think it worked for me with just the filename because I was loading files that were in the same folder from which I launched Pd. (I often run things from the terminal.) I guess it would be nice if instead, like with Pd abstractions, it would load paths relative to the location of the Pd patch file. Steve

Another odd thing I forgot to mention is that when I tried to launch pd from the terminal, and I was into the chuck~ build directory (since I had just copied the built files to my /pd/extra directory), pd segfaulted as soon as I opened a patch with the chuck~ object inside.

I'll try to replicate this to post the output error messages. IIRC they were about unknown symbols in chuck~.so.

This bug is an oddity of the PD open_via_path call. I think it should be fixed in the latest version here: http://www-static.cc.gatech.edu/ugrads/m/mjr/chuck~-0.1.2.tar.gz The next release should include Windows support and the ability to load ChucK scripts with paths relative to the patch file. martin robinson