<br><br><div><span class="gmail_quote">On 1/15/07, <b class="gmail_sendername">Vassili Slessarenko</b> &lt;<a href="mailto:urbanmuzak@urbanplexus.net">urbanmuzak@urbanplexus.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Wouldn&#39;t it actually be simpler to just run another cron job in how much<br>time you need for chuck to stop writing with &quot;chuck --kill&quot;? that way<br>you don&#39;t have to know anything about shreds or even programming chuck :)
</blockquote><div><br><br>Well, this scenario was refering to ChucK running without sound. This means that in a minute of real time ChucK could potentially be generating a hour (or several....) worth of sound to disk.<br>
<br>Type this at your terminal, just for kicks;<br><br>chuck --silent --loop<br><br>This will make ChucK do nothing as fast as it can and indeed take about 100% cpu time doing so. I imagine it could do loads of chuckian time per objective minute that way and it would become kinda hard to make cron timing refer to chuckian time.
<br><br>More sensible -to me- would be scheduling ChucK itself to run when it&#39;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 of tf the &quot;stopping all shreds&quot; question; By the time you stopped them manually you&#39;re probably awake.
<br></div><br><br>If learning about ChucK and shreds and stuff would be undesirerable we might as well call the whole thing off and either get a alarm-clock or take a gamble on the clarinet player(m/f) still being there in the morning (and waking before you do).
<br><br><br>:-)<br><br>Kas.<br></div>