[chuck-users] Crashage

[Kassen]

2008/5/24 thor <th.list at gmail.com>:


> Thanks. It was a rather difficult performance.


Maybe it's just me but I felt that got across in the music. I got a feeling
the music kept being pulled between "horror film drones" and something that
sounds quite jazz-like to me. I feel your difficulties are audible and only
enhance that contrast.


> I was using the ixiQuarks,
> trying to use only the live-coding possibilities of them and ignore the
> GUI elements and all this with a projected screen. Not what I normally do,
> but the context was such. Temporality or formal structures I find subtly
> difficult in live-coding. Live-coding is for the brave! Graham used ChucK
> in a great performance that night.
>

Formal structures I find hard as well, mainly because they mean you have to
plan ahead to a larger degree then I'm happy with. Still, with more practice
and perhaps more detailed facilities for updating structures in the future I
think that will be fine. Temporality (assuming you mean by that what I think
you mean) is one of ChucK's strong points, I don't have too much trouble
with it though those too can require a bit of planning.

Graham's piece is lovely as well, I still wonder how he did his edits that
cleanly, maybe he just has a great sense of timing in pressing the "update"
button.

But surely there must be some ways of creating good loops that result in an
> elegant crash?
>

There are plenty of ways to crash ChucK and in case of emergency you can
always call "Machine.crash()" which literally crashes the VM. I was just
having fun with the "crashing is cool" idea.


>
> In SC this would crash my computer in ca 30 secs:
>
> { inf.do({ {Saw.ar(999.rand, 0.01)}.play }) }.fork
>
> How would the ChucK crash loop look?
>

This looks to me like it just keeps creating saw oscillators and so
eventually bogs down the CPU, right? Your're not (that I can see) connecting
them to the output and Ugens not connected to a output in ChucK won't take
any CPU so in ChucK this'll get stuck on running out of memory. You could do
that like this;
====================8<==========
//don't run this; it'll likely get your memory and available swap-space full
//this may crash your computer resulting in data loss.
while(true)
  {
  //this will define a osc each iteration
  SawOsc s;

  //not sure how "999.rand" works exactly
  Std.rand2f(200, 2000) => s.freq;

  //this bit is easy
  0.01 => s.gain;
  }
=====================8<=============

I think that might be a port of your program. Not sure how soon it'll crash,
this will likely depend on how quickly your system can asign swap-space and
when it will say the process has alocated the maximum amount of memory it
can have. If that's less then what's available it might not crash the whole
computer at all.

It's not unlikely that ChucK's "watchdog" would complain about this being a
shred that endlessly loops without advancing time and would give you a
option to terminate it.

If you'd write it like this;
==============
while(true)
  {
  //note that now the osc has to calculate samples
  SawOsc s => dac;
  Std.rand2f(200, 2000) => s.freq;
  0.01 => s.gain;
  //try to fool the watchdog
  samp => now;
  }
===========

It will without any doubt be the CPU where it gets stuck, likely in less
then  30 seconds; ChucK is a lot less eficient than SC with with CPU time.
Of course allocating memory and/or CPU in a tight endless loop will get
anything stuck.

Amusingly, when I performed/compted in Marcel's event I rigged ChucK to
crash using Machine.crash() at the end of the alocated time but in the final
seconds I overloaded the VM so badly it didn't got round to running the
instruction to crash. Poor thing.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080524/5f0ad5ab/attachment.html>