On Fri, May 23, 2008 at 5:03 PM, Oliver Oli > wrote:

crashes in OS X, too :-)

awesome!!! i would love to research how to crash things, but nobody except my paternal and maternal instincts pay me well enough for this kind of job.

2008/5/23 thor :

Hey

Just dropping in.

Cool! I like your piece on the ogg LOSS compilation. (here; http://www.loss.access-space.org/lc_temp/ for those who don't have it and would like it; 2 and a half hours of livecoding music for romantic evenings and scaring pets)

Regarding crashes, this piece of art by the rastacoder Jaromil is a forkbomb that will fill the RAM of your computer and eventually crash it:

:(){ :|:& };: )

Beautiful. (still not typing it in though) I tried to crash ChucK in a more aesthetic way like this; ;<<<int tni >>>; but it wouldn't fall for it.

On Unix based operating systems, that is. Windows will just crash automatically without the need of such art.

Mine doesn't, my Windows install is completely stripped of all stuff I don't need on it and now it's very, very stable indeed. Of course there's ChucK but crashing ChucK keeps getting harder and harder because of those annoying dev's who keep taking the beautiful crashes away. ;¬) Kas.

Hello, There's an external for pd / max-msp called soundspotter designed for doing the kind of thing you want: http://www.soundspotter.org/ I'm not intimately familiar with it's workings, but it is open-source and Michael Casey has written several papers on the subject which you'll find under 'Research' on that page. So, if you definitely want to use ChucK (I'd suggest pd with that external may be the easiest route in the short term), there'll be lots of useful information there. If you did what you described with FFT, you would probably be vaguely on the right track, but I'm afraid it could turn out to be quite a long track... Good luck, it sounds like a fun idea; and soundspotter should be a perfect fit. Cheers, Peter On Fri, May 23, 2008 at 5:17 PM, Nuno Godinho wrote:

Hi,

Here's what I'd like to achieve:

There's a pool of samples of animals. There's a microphone. Someone talks to the microphone, the voice is analyzed and, based on a given similarity criteria, an animal is chosen.

To be honest I don't know how this can be done and if it is easy or hard. Should I try using FFT to determine, say, the main frequency and decide from there? Which other criteria should I be able to compare? Any links or samples to get me started?

Thanks, Nuno

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

Hi! Peter, SoundSpotter seems to be great. I tried to run it but didn’t manage to make it work. My fault because I did it in a rush. I’ll try it again if I do move forward with this idea because it seems to do exactly what I need. Rebecca, I’m very interested and curious about SMIRK. Please let me know once it’s totally up. Will, that would be well beyond my intentions, but it sure seems fun ;) Thanks you all! Nuno From: chuck-users-bounces@lists.cs.princeton.edu [mailto:chuck-users-bounces@lists.cs.princeton.edu] On Behalf Of Peter Todd Sent: sábado, 24 de Maio de 2008 0:48 To: ChucK Users Mailing List Subject: Re: [chuck-users] Analyse voice and choose animal Hello, There's an external for pd / max-msp called soundspotter designed for doing the kind of thing you want: http://www.soundspotter.org/ I'm not intimately familiar with it's workings, but it is open-source and Michael Casey has written several papers on the subject which you'll find under 'Research' on that page. So, if you definitely want to use ChucK (I'd suggest pd with that external may be the easiest route in the short term), there'll be lots of useful information there. If you did what you described with FFT, you would probably be vaguely on the right track, but I'm afraid it could turn out to be quite a long track... Good luck, it sounds like a fun idea; and soundspotter should be a perfect fit. Cheers, Peter On Fri, May 23, 2008 at 5:17 PM, Nuno Godinho wrote: Hi, Here's what I'd like to achieve: There's a pool of samples of animals. There's a microphone. Someone talks to the microphone, the voice is analyzed and, based on a given similarity criteria, an animal is chosen. To be honest I don't know how this can be done and if it is easy or hard. Should I try using FFT to determine, say, the main frequency and decide from there? Which other criteria should I be able to compare? Any links or samples to get me started? Thanks, Nuno _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

2008/5/24 thor :

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.

2008/5/23 AlgoMantra :

awesome!!! i would love to research how to crash things, but nobody except my paternal and maternal instincts pay me well enough for this kind of job.

Oh, they will. The position is called "alpha tester" or "quality control", I hear it's not so much fun as a job though. Not sure how to get that job, closest I ever got was getting audio software (good stuff too) in exchange for trying to make it misbehave. As far as crashes go this isn't as good as the one to make LiSa misbehave (I suspect) I ran into last night. That one made the "watchdog" offer to close the shred, then it didn't close the shred, then I could close the Mini but the noise went on. Now that's a quality crash... but of course the good ones like that are harder to find. Cheers, Kas.