April 2008 - chuck-users - lists.cs.princeton.edu

A problem with the code
by lucas samaruga 24 Apr '08

24 Apr '08

Hi list I'm working with ChucK in a musical project, and I have a problem with the code. This code generates 3 different error menssages in my machine (running chuck-alsa on linux), depending on the amount of components in an array. 1) A common [chuck](VM): NullPointerException: shred[id=3:grancassa.ck], PC=[13] 2) A segfault, and 3) A king of 1) + 2) problem [chuck](VM): NullPointerException: shred[id=3:grancassa.ck], PC=[13] *** glibc detected *** chuck-alsa: double free or corruption (!prev): 0x08391c50 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7c9d4b6] /lib/libc.so.6(cfree+0x89)[0xb7c9f179] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7eb4a61] /usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0xb7eb4abd] chuck-alsa[0x8055c25] chuck-alsa[0x80583aa] chuck-alsa[0x809b692] chuck-alsa[0x80564f9] chuck-alsa[0x8057ac8] chuck-alsa[0x80afd98] /lib/libc.so.6(__libc_start_main+0xe0)[0xb7c4cfe0] chuck-alsa(__gxx_personality_v0+0x3a5)[0x804dfb1] ======= Memory map: ======== 08048000-081a6000 r-xp 00000000 08:02 1107555 /usr/bin/chuck-alsa 081a6000-081ce000 rw-p 0015d000 08:02 1107555 /usr/bin/chuck-alsa 081ce000-08456000 rw-p 081ce000 00:00 0 [heap] b63c4000-b63c5000 ---p b63c4000 00:00 0 b63c5000-b6bc5000 rw-p b63c5000 00:00 0 b6bc5000-b6bc6000 ---p b6bc5000 00:00 0 b6bc6000-b73c6000 rw-p b6bc6000 00:00 0 b73c6000-b73c7000 ---p b73c6000 00:00 0 b73c7000-b7bc9000 rw-p b73c7000 00:00 0 b7bc9000-b7bcd000 r-xp 00000000 08:02 509500 /usr/lib/libogg.so.0.5.3 b7bcd000-b7bcf000 rw-p 00003000 08:02 509500 /usr/lib/libogg.so.0.5.3 b7bcf000-b7c1e000 r-xp 00000000 08:02 510590 /usr/lib/libFLAC.so.8.1.0 b7c1e000-b7c20000 rw-p 0004f000 08:02 510590 /usr/lib/libFLAC.so.8.1.0 b7c20000-b7c33000 r-xp 00000000 08:02 455207 /lib/libpthread-2.6.1.so b7c33000-b7c35000 rw-p 00013000 08:02 455207 /lib/libpthread-2.6.1.so b7c35000-b7c37000 rw-p b7c35000 00:00 0 b7c37000-b7d64000 r-xp 00000000 08:02 455181 /lib/libc-2.6.1.so b7d64000-b7d65000 r--p 0012c000 08:02 455181 /lib/libc-2.6.1.so b7d65000-b7d67000 rw-p 0012d000 08:02 455181 /lib/libc-2.6.1.so b7d67000-b7d6b000 rw-p b7d67000 00:00 0 b7d6b000-b7d75000 r-xp 00000000 08:02 455263 /lib/libgcc_s.so.1 b7d75000-b7d77000 rw-p 00009000 08:02 455263 /lib/libgcc_s.so.1 b7d77000-b7d9a000 r-xp 00000000 08:02 455189 /lib/libm-2.6.1.so b7d9a000-b7d9c000 rw-p 00022000 08:02 455189 /lib/libm-2.6.1.so b7d9c000-b7df2000 r-xp 00000000 08:02 1237590 /usr/lib/libsndfile.so.1.0.17 b7df2000-b7df4000 rw-p 00055000 08:02 1237590 /usr/lib/libsndfile.so.1.0.17 b7df4000-b7df8000 rw-p b7df4000 00:00 0 b7df8000-b7dfa000 r-xp 00000000 08:02 455187 /lib/libdl-2.6.1.so b7dfa000-b7dfc000 rw-p 00001000 08:02 455187 /lib/libdl-2.6.1.so b7dfc000-b7edf000 r-xp 00000000 08:02 510606 /usr/lib/libstdc++.so.6.0.9 b7edf000-b7ee2000 r--p 000e2000 08:02 510606 /usr/lib/libstdc++.so.6.0.9 b7ee2000-b7ee4000 rw-p 000e5000 08:02 510606 /usr/lib/libstdc++.so.6.0.9 b7ee4000-b7eea000 rw-p b7ee4000 00:00 0 b7eea000-b7fa1000 r-xp 00000000 08:02 509387 /usr/lib/libasound.so.2.0.0 b7fa1000-b7fa2000 r--p 000b6000 08:02 509387 /usr/lib/libasound.so.2.0.0 b7fa2000-b7fa6000 rw-p 000b7000 08:02 509387 /usr/lib/libasound.so.2.0.0 b7fa6000-b7fa7000 rw-p b7fa6000 00:00 0 b7fcc000-b7fe6000 r-xp 00000000 08:02 455174 /lib/ld-2.6.1.so b7fe6000-b7fe8000 rw-p 0001a000 08:02 455174 /lib/ld-2.6.1.so bfcf2000-bfd07000 rw-p bfcf2000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] Abortado I think there is not a NullPointerException in the logic of the chuck code, maybe I'm wrong, but the error menssages 2) and 3) are not only chuck-code-logic-problems. I can't understand the problem and find a workaround! If anyone can confirm that the error was due to a bug, or a mistake in my code, I will be grateful. Here is the simplificated code... //************** // grancassa.ck //************** // To Test: $ chuck CADSR.ck percaditiva.ck grancassa.ck public class GranCassa extends PercAditiva { int afinacion; 0 => int GRAVE; 1 => int MEDIO; 2 => int AGUDO; float bfreq; constructor(); fun void constructor() { //*********************************************************************** // setNComponentes < 5 // [chuck](VM): NullPointerException: shred[id=3:grancassa.ck], PC=[13] // setNComponentes = 5 // segfault // setNComponentes > 5 // [chuck](VM): NullPointerException: shred[id=3:grancassa.ck], PC=[13] // *** glibc detected *** chuck-alsa: double free or corruption (!prev): 0x083ae308 *** //************************************************************************ setNComponentes( 5 ); setResonancia( 10::second, 4.0 ); setAfinacion( GRAVE ); setGanancias( 0 ); } fun float tocar( float n ) { setTAtaque( 2::second, 0 ); n => g.gain; noteOn(); } fun float apagar( float n ) { if( n > 0.5 ) { setTApagado( 0.25::second, -2 ); } else { setTApagado( 0.5::second, 2 ); } noteOff(); } fun void setAfinacion( int a ) { a => afinacion; setFrecuencias(); } fun void setFrecuencias() { if( afinacion == GRAVE ) 40.0 => bfreq; else if( afinacion == MEDIO ) 80.0 => bfreq; else // afinacion == AGUADO 120.0 => bfreq; for( int i; i < ncomp; i++ ) { bfreq + bfreq * 0.5 * i + ( Std.rand2f( -2.5, 2.5 ) ) => s[i].freq; } } fun void setGanancias( int material ) { for( int i; i < ncomp; i++ ) { 1.0 / (i + 1.0) => gain[i].gain; } } } // Test GranCassa gc; <<< "np" >>>; gc.connectTo( dac ); while( true ) { gc.tocar( 0.5 ); 5::second => now; gc.apagar( 0.7 ); 2::second => now; } // End of grancassa.ck //**************** // percaditiva.ck //**************** // Super class for GranCassa public class PercAditiva { 12 => int MAX_COMP; int ncomp; SinOsc @ s[MAX_COMP]; CADSR @ env[MAX_COMP]; Gain @ gain[MAX_COMP]; Gain g; fun void connectTo( UGen ug ) { g => ug; } fun float setGain( float g_ ) { g_ => g.gain; } fun float getGain() { return g.gain(); } fun void setNComponentes( int n ) { if( n <= MAX_COMP && n >= 1 ) { n => ncomp; } else { <<< "(PercAditiva): Cantidad de componenetes no soportada" >>>; <<< "(PercAditiva): ncomp = 6" >>>; 6 => ncomp; } for( int i; i < ncomp; i++ ) { SinOsc saux @=> s[i]; CADSR caux @=> env[i]; Gain gaux @=> gain[i]; env[i].connectFrom( s[i] ); env[i].connectTo( gain[i] ); //s[i] => env[i].g => gain[i]; gain[i] => g; } } fun void noteOn() { for( int i; i < ncomp; i++ ) { env[i].keyOn(); } } fun void noteOff() { for( int i; i < ncomp; i++ ) { env[i].keyOff(); } } fun void setTAtaque( dur dt, float factor ) { for( int i; i < ncomp; i++ ) { env[i].setAttack( dt, factor ); } } fun void setTApagado( dur dt, float factor ) { for( int i; i < ncomp; i++ ) { env[i].setRelease( dt, factor ); } } fun void setResonancia( dur dt, float factor ) { for( int i; i < ncomp; i++ ) { //********************************************************* // Commenting the next line, no problem arise (¿?¿?¿?¿?) //********************************************************* env[i].setDecay( dt, float factor ); env[i].setSustain( 0.0 ); } } } // End of percaditiva.ck //********** // CADSR.ck //********** // CADSR = CurveTable + (stk)ADSR public class CADSR { CurveTable attack; CurveTable decay; CurveTable release; Gain g; dur atime; dur dtime; dur rtime; float acurve; float dcurve; float rcurve; float slevel; float clevel; // current level float rate; float step; int state; 0 => int ATTACK; 1 => int DECAY; 2 => int SUSTAIN; 3 => int RELEASE; 4 => int DONE; constructor(); fun void constructor() { setAttack( 0.5::second, 0.0 ); setDecay( 0.5::second, 0.0 ); setSustain( 0.5 ); setRelease( 0.5::second, 0.0 ); 0.0 => g.gain; } fun void connectTo( UGen ug ) { g => ug; } fun void connectFrom( UGen ug ) { ug => g; } fun void setAttack( dur t, float curve ) { t => atime; curve => acurve; } fun void setDecay( dur t, float curve ) { t => dtime; curve => dcurve; } fun void setSustain( float level ) { level => slevel; } fun void setRelease( dur t, float curve ) { t => rtime; curve => rcurve; } fun void keyOn() { // Si se ataca continua sin apagar, se mantienen los shreds // VERIFICAR spork ~ computeSamples(); me.yield(); // para darle oportunidad que corra el shred (?) } fun void keyOff() { if( state == DONE | state == RELEASE ) return; RELEASE => state; } fun void computeSamples() { if( state == ATTACK ) { // Las CurveTable se inicializan acá porque si no, hay // problemas con la inicialización y los índices. [ 0.0, 0.0, acurve, 1.0, 1.0 ] => attack.coefs; 0.0 => clevel; 0.0 => step; 1.0 / ( atime / samp ) => rate; while( state == ATTACK ) { attack.lookup( step ) => g.gain => clevel; rate +=> step; // La comparación debe ir antes de que se realize el // cómputo (pase el tiempo) por la concurrencia // de state con respecto a RELEASE. !!! if( step >= 1.0 ) DECAY => state; 1::samp => now; } } if( state == DECAY ) { [ 0.0, clevel, dcurve, 1.0, slevel ] => decay.coefs; 0.0 => step; 1.0 / ( dtime / samp ) => rate; while( state == DECAY ) { decay.lookup( step ) => g.gain => clevel; rate +=> step; if( step >= 1.0 ) SUSTAIN => state; 1::samp => now; } } // Este no if está demás por el paso del tiempo en el shred if( state == SUSTAIN ) { while( state == SUSTAIN ) { // clevel ~= slevel clevel => g.gain; 1::samp => now; } } if( state == RELEASE ) { [ 0.0, clevel, rcurve, 1.0, 0.0 ] => release.coefs; 0.0 => step; 1.0 / ( rtime / samp ) => rate; while( state == RELEASE ) { release.lookup( step ) => g.gain => clevel; rate +=> step; if( step >= 1.0 ) DONE => state; 1::samp => now; } } // Este if está demás (?) if( state == DONE ) { // por si las dudas 0.0 => g.gain; 1::samp => now; } } } // End of CADSR.ck Thanks Lucas

3 4

SqrOsc.width broken?
by Kassen 24 Apr '08

24 Apr '08

Dear list, SqrOsc (and SawOsc as well) seem to having a issue with their .width function, in particular; it doesn't work. PulseOsc and TriOsc are fine. It's not so clear to me how PulseOsc is different from SqrIOsc aside from this (I don't hear a difference, really). Depending on how "width" is seen TriOsc and SawOsc may be the same as well but with different dutycycles so perhaps there is no functional issue but it should probably still work as advertised. Demo for convenience pasted below. Yours, Kas. SqrOsc s => dac; while(second => now) { //this bit doesn't work Std.rand2f(.1, .9) => s.width; }

3 5

Re: [chuck-users] MAUI for PC/Linux
by pibsid＠suomi24.fi 23 Apr '08

23 Apr '08

Yes! Spencer your the man. Can't wait until I get my hands on that MAUI power to create the ultimate tetris clone for ChucK. Port to Linux first please ;) -Pyry Pakkanen >Spencer Salazar wrote: >As to porting MAUI to Windows and Linux, it seems clear that my >physical departure from the Princeton Soundlab has tempered my >miniAudicle-hacking vigor. However, given the current "swell" of >interest (4 people counts as a swell for miniAudicle) in porting MAUI >to other platforms, I think I can get back in the game and have some >results in the next few weeks. There should be something in CVS to >start playing with sooner--the basic structure of MAUI for Windows/ >Linux is implemented, its mostly a matter of filling in blanks and >testing. > >spencer >

6 10

Re: [chuck-users] Calculating Motion with Accelerometers
by Inventor-66＠comcast.net 22 Apr '08

22 Apr '08

Chris, Thanks for pointing out that 5-DOF limitation of sensing with a single 3-axis accelerometer, and also thanks for identifying that cool accelerometer/gyro chip that will be available soon. I had avoided considering gyro chips as the existing ones are much more expensive than today's accelerometer chips, but things are changing. As you can tell I'm just experimenting and imagineering a bit, and I haven't really thought this out to the level that a grad student or professor working in the field would. Mostly I'm just amazed at this sensor technology "revolution" that we seem to be enjoying presently. There are so many things that were talked about decades ago that are becoming realities today; I continue to be impressed with our society's technological progress. I guess the potential of HID's is old news to you and other more experienced ChucKists in general, especially since HID's appear to have been a ChucK feature for some time, but it's new to me and I'm excited about what I hope to do with them. Cheers. Les (Inventor)

1 0

the return of the abused models
by Kassen 22 Apr '08

22 Apr '08

Hi, list. Some time ago we talked about abusing the STK models for getting strange sounds, I found a nice new one using StifKarp. I was controlling the "stretch" parameter with my new tilt-sensing joypad and discovered that shaking the joypad led to nice noises. Here's a demo without the joypad for your enjoyment. Cheers, Kas. =========================== //"spooky sound" by Kassen. //Permission granted to modify and copy. //No warranties, no refunds, please mind your speakers and neighbours. //Remixing strongly encouraged. StifKarp s => dac; //low frequency for nice spooky sound 50 => s.freq; //the following lines are to have a note-on without actually //hearing the default pluck. StifKarp won't make a sound without one 0 => s.gain; 1=> s.noteOn; 2::second => now; //turn it up again .8=> s.gain; .9 => s.sustain; //exciting signal TriOsc lfo => ADSR env => blackhole; //works better if it's a sub-harmonic of the pitch, I think 25 => lfo.freq; second => env.attackTime; second => env.decayTime; .5=> env.gain; //connects the lfo's signal to the StifKarp "stretch" //see below spork ~ envctrl(); int counter; while(counter < 20) { 1=> env.keyOn; 3::second => now; 1=> env.keyOff; 1::second => now; counter++; } //allow it to decay for a bit 2::second => now; //bye fun void envctrl() { //the offset and the envelope's gain combine to //make sure the value stays in stretch's range while(10::ms => now) env.last() + .5 => s.stretch; }

1 0

Calculating Motion with Accelerometers
by Inventor-66＠comcast.net 22 Apr '08

22 Apr '08

Regarding methods for caclating motion with accelerometers: For the two sensor approach, you subtract the two linear accelerations to get an angular acceleration, and I believe you also divide by the distance between them. Then you integrate to get angular velocity and integrate again to get angular position (orientation). To get the X, Y, Z position you just pick one of the sensors and integrate to get velocity then integrate again to get distance. Now that I think about it, you'd have to remove the gravity vector by taking the high-pass filter of the acceleration with a low cutoff frequency first, or else by subtracting it off. The "trick", as i understand it, is to take advantage of the gravity vector so you only need one sensor. In this case you low-pass-filter the acceleration to get it's "DC" or "near-DC" component, which should give the orientation vector. Then you high-pass-filter the acceleration to get it's X, Y, Z component and integrate twice to get distance. It's a touchy sort of trick that requires tweaking and yes, it probably doesn't do so well with sudden motions. I'm not sure how well either would work, but I'm going to experiment and give it a try. Les (Inventor)

2 1

Re: [chuck-users] Bluetooth and Wiimote: a long-term feature request
by Inventor-66＠comcast.net 21 Apr '08

21 Apr '08

Thanks for the responses. I appreciate your thoughts, but have a different plan in mind. I am not going to do the tracking with the IR camera of the Wiimote, but rather with the 3-axis accelerometer inside the Wiimote. Normally one would use two 3-axis accelerometers and some signal processing to get a full 6-DOF (Degree Of Freedom) tracker, but there is a simple trick that uses only one. What you do is you obtain pitch, roll, and yaw from the gravity vector, or low-pass-filtered component, and the X, Y, and Z from the dynamic acceleration, or high-pass-filtered component. It isn't perfect but it does save you a sensor. Although it is possible to use OSC to get at a Bluetooth HID sensor, that sounds a bit over my head and would require a lot of effort and knowledge. It would be simpler to build a custom USB accelerometer using the Ultimark A-PAC Version 2 USB interface and one or two ADXL330Z accelerometers, on breakout boards from SparkFun Electronics. On the bright side, while exchanging posts with Kassen on the forum, we both separately noticed that there is a trend in the gaming industry, and we are expecting many new 3D mice and joysticks that are based on the now-inexpensive 3-axis accelerometer chips that are available from a few manufacturers. Kassen identified one for only $20 that hooks up to USB, looks like a joystick, and detects pitch, roll, and yaw. That's today, and in a few months there should be many to choose from. So my game plan is to wait a little while. Cash-wise, I am broke any way due to a massive car repair, so this will be a nice exercise in patience and careful planning, lol. What am I planning to do with a guitar tracker? Why, lots of stuff! I'm sure you can imagine the many things that could be done, and here are some of them. 1. Add increasing amounts of negative feedback as the guitar is pointed down to the ground, and positive feedback as it is pointed up to the sky. 2. Add reverb as the guitar is rotated toward the audience and echo as it is rotated back away from the audience. 3. Vary the feedback delay duration according to the player's leaning forward or back. That does something with all three orientation axes of pitch, roll, and yaw. Now that we've got the performer gyrating around on stage like Angus Young of AC/DC to access all of the tonal possibilities, let's deal with walking around on stage. If the player walks back to center, rear of the stage where the drummer would normally be in a typical rock band setup, the computer recognizes this and substitutes drums for the guitar notes that are being played. This is done with an FFT and a peak tracker, set up so that new fundamental frequencies trigger synthesized drum beats as they arise. The player may then record a drum loop by smacking the guitar, playing the loop, and smacking the guitar again. Now that drums are playing, the player walks to stage front, right where the bass guitar would normally be and ChucK's pitch shifter kicks in, making the six-string sound like a bass. Executing the same looping trick, the player initiates a repeating bass guitar riff. Now moving to stage front, left or stage front, center the player can then play the lead guitar part of the song as well as sing. To add to the tricks, singing in stage front, left creates a talk-box or vocoder type effect for those "Mr. Roboto" moments! that w e all enjoy. Finally, when the player jerks back on the guitar creating a gun-recoil motion as if something just shot out of the headstock of the guitar, that tells the computer to switch between modes. Planned modes are "normal", "thunderstorm", and "war". In these modes, the guitar plays through but each new note initiates a ChucK-based sound effect such as thunder or rain, else bombs, machine guns, and explosives. I'd like to pretend I'm Angus Young playing "Thunderstuck" with real thunderstorm sounds under guitar control. The angular and positional features previously described are available in all modes. Also, I should probably mention that my secret motivation for doing this is to create some kind of exercise machine that I will actually use. If I need to bend over or walk around to achieve various guitar effects, I'll probably actually do it and get a mild workout. Then I will become a leaner, meaner, guitar-playing ChucKist, or so I hope. Do you have any other wild ideas for what to do with an instrument tracker? As always, I welcome your comments and suggestions. "Forget all about that macho stuff and learn how to ChucK guitar!" Les (Inventor) p.s. I sent an email to Fender, the famous guitar manufacturer, suggesting the above. Who knows, maybe they'll make a guitar tracker product for us to enjoy.

5 8

1.2.1.1 ASIO? Please?
by Kassen 21 Apr '08

21 Apr '08

Fellow ChucKists, Does anybody have a win-ASIO version of 1.2.1.1 or the time and means to roll me one? Please? I know it's only a minor upgrade over 1.2.1.0 but I really need the updated Envelope on Windows with good latency. Electro-music.com would have space for hosting or a attachment to me would be fine as well. Let's not send files that size to the list. Yours, Kas.

2 3

Simple percussive sound synthesis
by Jeff Smith 20 Apr '08

20 Apr '08

I'm interested in exploring sound synthesis using ChucK.In particular I'm interested in algorithmic synthesis of simple physically-based sounds, like a water drip or a hand-clap. Does anybody have any examples lying around that create a sound like this from scratch? I'm a complete noob when it comes to audio signal synthesis, and I'd love to see how others have approached building up the sound. -- Jeff Smith Computer Science Dept. University of Saskatchewan

4 5

Guitar HID
by Inventor-66＠comcast.net 20 Apr '08

20 Apr '08

> Although it is possible to use OSC to get at a Bluetooth HID sensor, that sounds a bit over my head and would require a lot of effort and knowledge. It would be simpler to build a custom USB accelerometer using the Ultimark A-PAC Version 2 USB interface and one or two ADXL330Z accelerometers, on breakout boards from SparkFun Electronics. Actually, I tried sending Midi from Osculator (osculator.net) once (using my wiimote to control the pitch of a Nord Modular), and that wasn't very hard at all. For me at least, it is several orders of magnitude easier than the hardware stuff you suggest :) And since the site says Osculator supports OSC forwarding (gotta try that out later), and receiving OSC messages in ChucK is a breeze, that should be worth checking out. That is, if you use a Mac :/ /Stefan HaHa, I guess we're different animals, Stefan, as a hardware approach seems easier to me. I did get some excellent help from some folks on the forum and tried to compile a program to do this, but it wouldn't compile. Apparently I need dependency files, sigh. Then I started realizing what I really should have realized first, which is that the code is for Linux only and I'm on a Mac, plus none of my machines even have a Bluetooth interface! So the Wiimote is not a solution for me just yet. It looks like USB is going to be best for my situation. Also one nice thing about the whole project is that it's by no means a one-shot deal. I'll likely end up with several HID products before I'm done. I started getting a little stressed out about choosing the right sensor, but when I realized that it will be a journey and a process rather than a decision, I felt a lot more relaxed about it. So I'm jumping on the HID bandwagon, albeit ever so slowly. Les (Inventor)

1 0