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

recording
by joerg piringer 05 May '08

05 May '08

hi list, sorry if this has been asked before (i didn't read the list closely the last months): is it possible that recording from dac is broken with the latest chuck version (or miniaudicle) on winXP? i always get silent wavs or even unreadable. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/

5 10

Create your own scratch pad!
by Martin Ahnelöv 04 May '08

04 May '08

<http://www.metacafe.com/watch/849223/how_to_make_your_own_scratchpad/> cheers, Gasten

4 4

audio source in linux
by AlgoMantra 03 May '08

03 May '08

Apologies if I sound bloody ignorant in this: I gather that most linux-based audio programming systems would be playing with some basic interface provided by the system. I wonder for instance if some basic sounds can be produced using the shell or some kind of very rudimentary program that instructs the sound card to, say, produce a square or sine wave. As it is a stream of numbers, I wonder what is that underlying process which converts it to sound? If I'm not wrong, both pure data and ChucK would be using this same underlying system in Linux. Can anyone elucidate with an example? I'm just trying to look beneath the surface here... ------- -.- 1/f ))) --. ------- ... http://www.algomantra.com

2 4

[OT] May Day Fun: CD release from PGT
by Brad Garton 01 May '08

01 May '08

Hey chucksters -- Pardon the spam, but there *is* some chuck-ing going on 'behind the scenes/sounds' in this one (using [chuck~], of course!): ---------------------------- PGT: "Temporary Habitations" Crown (29:02) Minuit (17:09) Dome (24:55) The first CD release by PGT, a trio composed of Terry Pender (mandolin), Brad Garton (laptop), and Gregory Taylor (laptop) is an intimate snapshot of the improvising ensemble - three pieces that take their names from referential scraps of the place names where they were recorded around the time of the trio's various recent public performances. This set of nomadic documents can be thought of as a live recording made in a single, moveable location - homes away from home, where friends meet in interchangeable rooms to pursue the pleasure of playing together while awaiting the opportunity to play for others. In the quiet of those convivial mornings, afternoons, and evenings, new timbres and timescales emerge as PGT take the opportunity to try new things away from the distractions and expectational inertia of the club or concert hall. website/order on-line: http://music.columbia.edu/~brad/PGT/Temporary_Habitations/ additional info/mp3-recording links: http://music.columbia.edu/~brad/PGT/ Loochtone Recordings :: 602 Russell Street :: Madison, WI 53704 ---------------------------- who we are: Terry Pender (http://music.columbia.edu/~mando) is a composer and musician whose interests range from contemporary multimedia-based works to Irish music and the mandolin. His works have been performed worldwide, including Japan, China, and Greece, as well as across the United States. He has composed for NPR, national network television, and the Whitney Museum of American Art. Lately he has been creating sound designs for large scale public art works with the Open Ended Group. He was the editor of "Mandolin Quarterly", an internationally distributed magazine, and his music is published by NL Publications, Inc. He is an Adjunct Assistant Professor of Music and the Associate Director of the Computer Music Center at Columbia University. Brad Garton (http://music.columbia.edu/~brad) received his BS in pharmacology from Purdue University, where he also worked towards an MS in psychoacoustics. He eventually entered the graduate music composition program at Princeton University (studying primarily with Paul Lansky and J. K. Randall), where he was awarded PhD in music composition. He is currently a professor on the faculty of Columbia University, where he also serves as Director of the Computer Music Center. He is an active composer and music software developer, and has worked as consultant on the design and installation of computer music facilities throughout the world. Gregory Taylor (http://www.rtqe.net/) was trained initially as a visual artist, He has studied central Javanese gamelan and electroacoustic music in the U.S. and the Netherlands, written for publications such as Wired, Array, and Option, and hosted a radio program of contemporary audio since 1986 (http://www.rtqe.net). In addition to his work with PGT, he has released solo recordings on c74, Palace of Lights and Stasisfield, performed and recorded as The Desert Fathers with quartertone trumpeter Jeff Kaiser, and remixed artists such as Scott Fields, Kim Cascone, and BMB.con. He currently labors on behalf of the new media software company Cycling '74.

1 0

reference sub-sections of multi-dimensional arrays
by eli queen 30 Apr '08

30 Apr '08

hi all ... this is my first post to the list. so, as you would guess, i'm new to chuck. the question ... i'm working on a class with following functionality: serial 12 tone row in > calculate a 12 tone matrix (2D array) > lookup indexed rows (transposition) and/or lookup indexed columns (inversion) > output lookups as 1D arrays the row (x) part is simple: array2D[ row# ] @=> int array1D[]; but, is it possible to reference the y subsection of a 2D array? i know i could do it with a function i.e.: int i[12]; fun void invrton ( int y ) { for (0 => int x; x < 12; x++) { toneRow.matrix[x][y] => i[x]; } } invrton(1); this will assign i[] as values of column i(1), but is there a way w/o the function? i'll most likely put both lookups in the public twlvTone class so the patterns can be accessed by shered-ed instruments. anyway ... here's the full code: public class twlvTone { int matrix[12][12]; fun void setMatrix ( int p0[] ) { for (0 => int x; x < 12; x++) { for (0 => int y; y < 12; y++) { (p0[x] + ((12 - p0[y]) % 12)) % 12 => matrix[y][x]; } } } } twlvTone toneRow; toneRow.setMatrix( [0, 11, 7, 8, 3, 1, 2, 10, 6, 5, 4, 9] ); <<< toneRow.matrix[0][5] >>>; toneRow.matrix[1] @=> int t1[]; <<< t1[11] >>>; thanks, eli

2 1

fixin' build on non-Mac platforms
by Stephen Sinclair 29 Apr '08

29 Apr '08

Hi, There's currently a couple of missing stub functions in the CVS which breaks the build for non-Mac platforms. Here's a patch. Steve

1 0

osc listener shred woes
by mike clemow 29 Apr '08

29 Apr '08

Hello all, So, the following code sporks out two shreds to listen for two (for now--I want to be using 14) OSC messages, put their int values into an event and report back to the parent shred with the value and the address. This is supposed to be a way to get around the fact that, a) I seem to have to listen on a different port if the OSC messages have the same type, b) that I can't wait on multiple events and, c) that I want all the values to control parameters in a single patch. My OSC messages are being lobbed at Chuck via a Python script and everything seems to be working fine on that end. I've even gotten this to work using two chuck shreds that were manually sporked. At any rate, this code runs fine for about two seconds and then dies in either a segmentation fault or a bus error. Any guesses? --- // extend the Event class class Bang extends Event { string message; int value; } // a generic osc listener shred fun void oscListener( Bang b, int port, string osctype ) { // create our OSC receiver OscRecv recv; port => recv.port; recv.listen(); // create an address in the receiver, store in new variable recv.event( osctype ) @=> OscEvent oe; while( true ) { // wait for osc event to arrive oe => now; while( oe.nextMsg() ) { oe.getInt() => b.value; osctype => b.message; b.broadcast(); } } } // our event "Bang" Bang bang; 8000 => int oscport; // the types for the osc objects "/leftraw, i" => string leftraw; "/leftavg, i" => string leftavg; spork ~ oscListener( bang, oscport, leftraw ); // shreds are usually happier listening on a separate port spork ~ oscListener( bang, oscport + 1, leftavg ); SinOsc raw => dac; SinOsc avg => dac; while( true ) { bang => now; //<<<bang.message, bang.value>>>; if( bang.message == leftraw ) { bang.value => raw.freq; } else if( bang.message == leftavg ) { bang.value => avg.freq; } }

5 18

Time-stretching without changing pitch
by Nuno Godinho 28 Apr '08

28 Apr '08

Hi, For a video installation I need to create a module to do interactive time-stretching without changing pitch. This will use a WAV file as input but the speed will change interactively based on an OSC parameter. But to make it simpler let's say the playback speed depends on the mouse speed. I understand there are two ways to achieve this: FFT and Granular Synthesis. The granular synthesis example that comes with Max/MSP almost does this out-of-the-box, but I would like to try to avoid and use ChucK instead. But, even though I've read the manual and understood some of the examples, I'm still very Chuck-ignorant and have no experience whatsoever. Since now ChucK is able to do FFT I was wondering how easy it is to implement this on ChucK using FFT. On the other side, some documentation I've read on time-stretching suggests that the simple FFT process creates lots of artifacts and there has been a lot of research on this and several improved methods were proposed. This scares me because I would like to melt my brain learning all the details, since that Max/MSP patch already does something quite close to what I need. Has anyone done (or knows how to do) time-stretching on ChucK? Should I go for FFT or Granular Synthesis? Any help is welcome. Thanks in advance! Nuno

4 5

Processing --> ChucK, was: MAUI for PC/Linux
by Michael Heuer 27 Apr '08

27 Apr '08

mike clemow wrote: > ... > When I run a UI I made in Processing to control Chuck, Chuck doesn't even have to be > running on the same machine, since all the control messages are sent via UPD as OSC > messages. Processing --> Chuck? Very cool. I would be very interested to see what you have done from the Processing side. I have a lot of libraries in java for e.g. genetic algorithms, neural networks, etc. that I would love to drive ChucK with but hadn't found a good mechanism to do so. I had been going about the re-write the java libraries in ChucK syntax task but without namespaces and resizeable arrays that is becoming tiresome. michael

3 2

mailing list archive certificate
by Kassen 25 Apr '08

25 Apr '08

Hi, list! small note; with the new Ubuntu that's out now I switched to Firefox3 and Firefox now insists it's having a problem with the security certificate on the list archives. I'm not sure why the list archives need to be that secure, after all we don't check the identity of people sendining mail to the list either but if we have a certifficate it should work, I think. Brief browser info pasted below, I'd be happy to supply more info if needed. --------------- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5 --------------- For now I had Firefox add a exception for this certifficate. I'm quite sure this list isn't the right place to mention this but I also have high hope somebody on the list will have the address of the Princeton SC mailserver admin. Yours, Kas.

1 0

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

25 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

Re: [chuck-users] A problem with the code
by pibsid＠suomi24.fi 19 Apr '08

19 Apr '08

A quick glance over your code suggest that the seq faults are caused by float functions that do not return anything. Try: fun float foo(){ return 0.0; //remember to return a float } The null pointer exceptions are propably caused by using SinOsc @ s[MAX_COMP]; This creates an array of null pointer SinOscs. Try without the @: SinOsc s[MAX_COMP]; -Pyry Pakkanen

1 0

Bluetooth and Wiimote: a long-term feature request
by Inventor-66＠comcast.net 17 Apr '08

17 Apr '08

I've been researching 3-axis accelerometers and have decided to build my own joystick HID unit. This will require custom homemade circuit board construction, though not much of it, and the purchase of two $35 circuit boards from the web. So no problem, it should work great and then I can code ChucK to know the position and orientation of my guitar at any moment in time. ChucK can then do many interesting special effects to the guitar sound with that information, freeing the player from clumsy pedals and such. It should be kewl, but along the way I learned that there are many Bluetooth HID products which would have done the job without any special circuitry at all. In fact, a $50 Wiimote - the remote control for the Wii console game - is a perfect little instrument tracker plus it has buttons and such as well, but ChucK doesn't know how to talk to a Bluetooth sensor. So you can see that there is good reason to add Bluetooth HID to the list of ChucK's features. I wouldn't place it at high priority since the dev team is currently so pressured with feature requests and this is only one application. Still, I wonder if such a feature as Wiimote instrument tracking might help to popularize ChucK? Whatever, just making a feature request. I added it to the bottom of the Wiki feature request list. Keep on ChucKin'! Les Hall (Inventor)

4 3

OSX updates =< real-time audio?
by Ge Wang 16 Apr '08

16 Apr '08

Greetings, We are experiencing some rather unfriendly real-time behavior on OS X, seemingly after doing the latest apple upgrades... here are some details, at least on my machine: * system: Macbook Pro / OS X (10.4.11) * updates: Quicktime 7.4.5 + MPB EFI Firmware Update 1.5 * symptoms: real-time audio "goes to poop", even under moderate loads. * workaround: running command line chuck in BLOCKING mode (via --blocking) seems to work, however the default CALLBACK mode seems completely hosed, even with bigger buffer sizes. This is especially problematic for the miniAudicle, which doesn't have the option currently to choose between blocking vs. callback. Has anyone else noticed similar behavior, either on Tiger or Leopard? Or is this an isolated case for my system? We'd appreciate any input! Thanks!! Best, Ge!

6 8

low overhead interpolation trick
by Kassen 12 Apr '08

12 Apr '08

Dear ChucKists. I was running out of fingers and buttons on my joypad... who-ever decided the thumbs should share both the analogue sticks and the buttons on the top? Anyway, I picked up a tilt-sensing joypad. Sadly proper tilt sensors are relatively expensive and games devices typically get made as cheaply as possible (grumble). To cut a long story short; it sends a fury of values that are somewhere around the value that it needs to be. Result; the poll-rate gets to be a kind of noisy harmonic. So; this leads to the question of how to interpolate this mess without making complex function calls at this high poll-rate and cook the poor CPU before we get any sound made at all. Solution; as soon as I get the value the axis moved to I write that to a Step Ugen's ".next()". Then; Step my_axis => LPF my_interpolation => blackhole; //set to taste, it's latency v.s. noise //maybe a rate that's relatively prime to the poll-rate would be best? 5 => my_interpolation.freq; then my_interpolation.last() can be polled at whatever rate makes sense. It can also be chucked directly to Ugens like oscillators set to act as a FM synth (use the filter's gain to scale) or to Gain's set to multiply. Very cheap and so far quite pleasant to work with, I thought I'd share. Yours, Kas.

3 3

Future ChucK: wish list items and one comment
by Inventor-66＠comcast.net 02 Apr '08

02 Apr '08

Dear ChucKists, I look into my crystal ball and I see the future of ChucK, AKA my wish list: o MAUI ported to PC/Linux (on the way, woohoo!) o fix noteOff () problem o String Processing: preferably inspired by Perl o File I/O: I want to save and load program settings o printf (): formatted text/numeric output. o Hierarchical Events: i.e. event when any button in an array is pressed o MAUI Expansion: Text I/O, File Browser, 2D drawing, 3D drawing, etc. o Garbage Collection o Tube Amplifier UGen o Piano STK Instrument And there is one observation I'd like to share... Aside from it's musical capabilities, the one outstanding feature of ChucK to me is the way that everything works together. ChucK is very Apple/Linux-like in the way that it seems to be so well thought out. Of the dozen or two languages I've played with over the years, ChucK has got to be the most fun and the easiest to code because stuff just plain works. So my hat's off to the dev ChucKists, us user ChucKists are having a blast with your hard work! Inventor p.s. I went retro on the Pong game with the square ball as I remember from our Pong unit we had as kids, though I agree the LED would be way cooler. Maybe make it blink all three colors...

7 8