[chuck-users] generating a wav|mp3 unattended via cron

[Vassili Slessarenko]

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* <w3gw3rfadr3553 at googlemail.com
> <mailto:w3gw3rfadr3553 at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users