On 01/15/2007 10:54:42 AM, Kassen wrote:

I believe that official policy is still that ChucK shouldn't be used in anything aplication that requiers reliability, including but not limited to nuclear reactor management, public performance and especially alarm-clocks.

awe, c'mon.... ChucK is AT LEAST as reliable as a clarinet! :-) .pltk.

Wouldn't it actually be simpler to just run another cron job in how much time you need for chuck to stop writing with "chuck --kill"? that way you don't have to know anything about shreds or even programming chuck :) Kassen wrote:

On 1/15/07, *Wegwerf Adresse* mailto:w3gw3rfadr3553@googlemail.com> wrote:

Hello list,

my first posting, I am not so much a musician as rather interested in hoe our digital technology advances. ChucK caught my attention with its interesting mixture between programming and creativity.

Hi, Chris, you wouldn't be Dutch by any chance? (I noticed the "hoe" above...)

I would like to generate this piece on a soundcard-less server, preferably without my intervention (via cron).

Sounds like a good plan.

I found the '--silent' option to suppress audio output and a file rec-auto.ck http://rec-auto.ck to record into a wav file.

Exelent, you are nearly there already.

But that way the recording-to-file doesn't stop, it keep growing bigger. I also could not find anything in the docs.

Right. So; what we need is something to stop the recording to the file and indeed preferably something to stop chuck completely. What you could do is start chuck in a non-looped way ("chuck --silent filename.ck http://filename.ck record.ck http://record.ck" would do). Now if something would remove all shreds from the VM chuck would shut-down and in this process should close the recorded file.

So if your record.ck http://record.ck would machine.add() a shred who's sole purpose would be to wait for -say- ten minutes (of ChucK time), then remove all shreds (and itself at the end too) then you'd be in business.

Now it gets a bit hard because it's not always obvious what the ID of the last shred is and we need a ID to remove shreds. If for your sounds you can easily establish the ID of the highest shred I'd recommend something like this;

10::minute => now; //kill all lower id's then self for(0 => n; n< me.id(); n++) Machine.remove(n); //then everything higher for( (me.id() + 1) => n; n < highest_shred_id; n++) Machine.remove (n); //somebody has to turn the light out... m.exit();

Don't spork this as a function; if you do it will be killed when the parent that sporked it is killed.

When you don't know the ID of the highest shred that's not a child (killing parents kills their childeren) then it gets a bit harder. what you could try is Std.system() which send a request to the OS. "Std.system( chuck --kill)" should make chuck request that the system kill it. Theoretically. I think I saw some weird behaviour coming from Std.system and IMHO " Std.system( chuck --kill)" is pushing the envelope of what's sensible to do (but it's kinda fun because of that).

So what is a good, reliable way to create music files?

I believe that official policy is still that ChucK shouldn't be used in anything aplication that requiers reliability, including but not limited to nuclear reactor management, public performance and especially alarm-clocks.

> I want my computer to create a file every other week and use it as an alarm clock in the morning. ;)

I recommend making sure your algorithems *always* generate a sound. Silence is a sound too, or so I was told, but silence isn't a alarm-clock. ;-)

Kas.

------------------------------------------------------------------------

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

Hi guys, thanks for your input! I think I will take the hard way, although I don't understand much of what was written. That particular "In C" piece is of a variable length, so a cron kill is not a good idea. Admittedly I thought there was an easy option "switch". But I will see if I can live up to that challenge! ;) btw, I am from Germany, somewhere north of Frankfurt. 2007/1/15, Kassen :

On 1/15/07, Vassili Slessarenko wrote:

...

Wouldn't it actually be simpler to just run another cron job in how much

More sensible -to me- would be scheduling ChucK itself to run when it's time to wake up. You could even make a snooze function that would silence it for five minutes after hitting the keyboard. This will also take care