2008/5/24 thor <th.list@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.