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

granular music recommendations?
by AlgoMantra 23 Jul '24

23 Jul '24

Yo All....I'm trying to download and study some of the best music out there which features granular synthesis. I haven't heard much yet beyond Iannis Xenakis, but I'd love to know what your favorites are. Perhaps it would be worthwhile putting up a torrent of the same. If possible, kindly provide links to mp3 files or any other type of free downloads. (What do you think of Jaron Lanier's music?) http://www.jaronlanier.com/musicdownload.html cheers! ------- -.- 1/f ))) --. ------- ... http://www.algomantra.com

12 28

UGen based Pitch tracking demo
by Kassen 30 Dec '08

30 Dec '08

Fellow ChucKists, There was a question on the forum about tracking the pitch of a Theremin. FFT-based techniques may be the most obvious choice for attempting to track a pitch in general but I felt that such a simple signal could be tracked by some modest UGens. Below you'll find a class that counts zero crossings over a given duration, tracking them in real time and outputing a value corresponding to the pitch (in Hz) of the input signal. I did in "mock UGen" form because of the tracking ability of the plain oscillators (see usage example below). Might be useful in some cases or good for amusement value. Thanks to Frostburn for teaching me the OnPole+Delay trick this is based on; turns out it's good for more then just calculating the average over the last n samples. Please note; when you see people with a flute next to a modular synth; there is a good reason why they are using a flute and not a more complex signal; this is a very primitive method. Yours, Kas. //----------------8<------------------------------------------------- //zero-crossing based pitch tracking by Kas. //permission granted to copy, redistribute, extend and/or remix. //no warranties, no refunds. //please mind your speakers and neighbours. PitchTrack p; adc => p.in; p.out => SawOsc s => dac; //make the SawOsc track the PitchTrack's output. 0 => s.freq; 3 => s.sync; .10::second => p.avgTime; hour=> now; class PitchTrack { //primitive pitch tracker based on zero crossings. //counts the zerocrossings over a certain duration (default is one second) //suitable for demonstrating the power of UGens //suitable for whistling saw-waves //not suitable for complex input signals. //however, this will continuously and smoothly (attempt to) track a signal, unlike fft Gain in => ZeroX x => FullRect f => OnePole avg => Gain out; f => Delay d => avg; //make the averaging filter simply stack up all input values //here it is counting how many zero crossings it's seen -1 => avg.a1; 1 => avg.b0; //remove incoming values after a second //Thanks to Frostburn for this trick 5::second => d.max; second => d.delay; -1 => d.gain; //compensate for tracking two crossings per cycle .5 => avg.gain; //========member functions===================== //sets time to average the input freq over. //reaction speed v.s. accuracy fun dur avgTime( dur length) { if (length < samp) { <<<"warning, duration too short, correcting">>>; ms => d.delay; } if (length > d.max()) { <<<"warning, duration too long, correcting">>>; d.max() => d.delay; } else length => d.delay; .5 * (second / d.delay() ) => avg.gain; return d.delay(); } //returns this time fun dur avgTime( dur length) { return d.delay(); } //pretend we are a UGen //note this value will start at 0 and we still need a blackhole to operate fun float last() { return avg.last(); } }

1 0

ChucKian greetings and updates!
by Ge Wang 30 Dec '08

30 Dec '08

Dear all, Greetings from the ChucK team - all the best wishes in the coming year! I want to take this opportunity to bring you up to date on things of ChucKian nature, and also to address what's next. I hope this reads more like um cliff notes than a newsletter (because the latter can seem really boring)! It has been a fairly insane year for all of us at the ChucK team, ranging from new research, an expanding community, a new lorchestra, publications (including a dissertation), to ChucK helping to power a new startup making crazy sonic software for the iPhone. Here is a partial summary, mostly in a strongly-timed ordering: * Continuing our investigation on audio analysis in ChucK: Rebecca, Perry, and I have begun to explore new directions involving on-the-fly learning and support for MIR prototyping in ChucK. Check out the all new sMIRk and publications: http://smirk.cs.princeton.edu/ * PLOrk's west coast offspring/sibling, SLOrk (Stanford Laptop Orchestra) was instantiated; ChucK is used as the primary platform for instrument design, sound design/synthesis, and teaching: http://slork.stanford.edu/ http://slork.stanford.edu/media/ * By the way, PLOrk is about to enter a new level of insanity in spring 2009, with an MacArthur-supported campaign that features an fully expanded, rebuilt ensemble and an unbelievable lineup (Matmos, So Percussion, and Laurie Anderson): http://plork.cs.princeton.edu/ * PhD Dissertation: "The ChucK Audio Programming Language: An On-the-fly, Strongly-timed Environ/mentality" was completed, almost fatally injuring its author and his PhD committee in the process: http://www.cs.princeton.edu/~gewang/thesis.html * Smule was found in Summer 2008, exploring what we call "Interactive Sonic Media", starting with the iPhone. ChucK on the iPhone (ChiP) serves as the core platform and engine. Perry, Spencer, Rebecca, and I are all part of the madness: http://www.smule.com/ http://www.smule.com/about/ http://ocarina.smule.com/ http://www.youtube.com/watch?v=kfrONZjakRY&fmt=18 * Meanwhile, the ChucK community continues to grow both in and out of academia. We especially would like to call out the inspiring efforts of Kassen (sporksperson, forum moderator, and ChucKian sherpa), Inventor, Stephen Sinclair, Ajay Kapur, Adam Tindale, Paul Botelho, Dan Trueman, PLOrk/SLOrk, and others for the immense guidance, ideas, and creativity they provide on the forum, mailing lists, as well as in classrooms and onstage. --- >From our point of view, it has indeed been a busy year of ChucKing. What's next? * One common question concerns ChucK on the iPhone. Here is where things stand: ChucK has ported to the iPhone by Smule, and has served as the audio platform behind its products (Sonic Lights, Ocarina, etc.). While ChucK is freely available on OS X, Linux, and Windows (and shall remain so), we have not yet opened ChiP, our ChucK on iPhone engine/port (nor do we license this platform currently). While we can't make any promises, we articulate that the core team would like to explores ways to open ChiP by creating an beneficial environment for everyone (researchers, artists, smule, developers). Again, we can't make any promises and it is a possibility that ChiP will not be open sourced for the foreseeable future, but we genuinely want to make it open and make it work, and are exploring that possibility. * Along this line, we would like to articulate the following point: major general language features that are introduced as part of ChiP *will* be fully released in the main distribution (only iPhone/smule-specific features will remain proprietary for now). This is by design when we structured Smule. You see, most of us at Smule care about, use, and release open-source software, and we genuinely want to build an ecosystem where things can be as open as possible and remain mutually beneficial. We shall keep moving forward in this way. * ChucK releases: it's been a while since the last release, so perhaps not many are holding their breath for the next release. It's coming, for better or for worse!! File IO is finally in place, along with several other features. miniAudicle MAUI for Windows and Linux are nearing completion as well. Stay tuned! * ChucK research, development, and pedagogy continues in full, at Princeton, Stanford, and with quite a few other institutions and individuals. Rebecca leads the charge on MIR/on-the-fly learning/analysis-based performance, new features/uses are developed by Perry, Dan, researchers and students at Princeton, and by us at CCRMA, and now at Smule. At Stanford, we are also working on new systems based on ChucK, code, and interaction to provide new ways of working with audio. Stephen Sinclair, Kassen, Inventor, Ajay Kapur at CalArts, and Adam Tindale in Calgary continue to contribute code and ideas. Admittedly, incorporating contributions has been an issue, and this is squarely my fault for not having better coordinated due to cycle shortages. For what it's worth, I am just going to accept that the load not going to get any better and will endeavor to re-organize! Well, that's all I have for now - and it's amazing if you read this far! Please send all thoughts, complaints, suggestions to the chuck-users list, forum, or just email us! >From all of us on the ChucK team, we wish you a wonderful new year and beyond! All the best, Ge, on behalf of ChucK team

4 3

ChucK fails to compile on GCC 4.3.x (BUG)
by Kassen 29 Dec '08

29 Dec '08

As documented by forum members PopCode and Nomic ( http://electro-music.com/forum/viewtopic.php?t=30859 ) the Mini no longer builds on Ubuntu since the latest LTS update which also updated GCC. In particular the process dies while trying to compile the VM so that almost certainly means ChucK itself won't build under Ubuntu or with the new version of GCC either. The fatal error; ---------------------8<-------------------------------- g++ -D__LINUX_ALSA__ -c -O3 -D__CK_SNDFILE_NATIVE__ chuck_vm.cpp chuck_vm.cpp: In member function 'long unsigned int Chuck_VM::process_msg(Chuck_Msg*)': chuck_vm.cpp:1007: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' chuck_vm.cpp: In member function 'long unsigned int Chuck_VM_Stack::initialize(long unsigned int)': chuck_vm.cpp:1373: warning: too few arguments for format chuck_vm.cpp: In member function 'void Chuck_VM_Shreduler::status(Chuck_VM_Status*)': chuck_vm.cpp:2078: error: 'sort' is not a member of 'std' make[2]: *** [chuck_vm.o] Error 1 make[2]: Leaving directory `/home/ghost/Desktop/miniAudicle-0.1.3.8/chuck-1.2.1.1/src' make[1]: *** [chuck] Error 2 make[1]: Leaving directory `/home/ghost/Desktop/miniAudicle-0.1.3.8' make: [linux-alsa] Error 2 (ignored) -----------------------8<---------------------------------------- Nomic found that the culprit is GCC 4.3.x being more strict than 4.2.x (details on the linked page). This is in adition to a storm of warnings about a depreciated conversion that seem to be caused mostly by WXW so those may be beyond our scope? I'm adding this to the WiKi's bug page. Yours, Kas.

2 2

Blob (was; Physics Engine In Chuck)
by Kassen 28 Dec '08

28 Dec '08

Steve; Yeah sorry I haven't had time to mess with this more lately. > Maybe I'll get back into it throughout the christmas break. > I'm a little wary of doing it without discussion with the official > chuck devs, maybe we should discuss the idea more on chuck-dev@. > I agree. IMHO the core of what ChucK's development will need in the future is de-centralisation and communication. To me it's clear that we have people around that can write a decent UGen or two and we have plenty of people who can test such things. If some people verify a certain new UGen works, is stable, useful and relatively efficient I feel it should need no more then a glance of one of the main DEV's to be included in the main build. There will be bugs anyway and we'll find them, no big deal. If we had a shortage of people willing to risk their computer and sanity on untested ideas we wouldn't be here :¬). The same goes for the manual,etc. I'm no project leader, I have next to no experience with this type of process so take my words with a few lumps of salt. It's my impression that our main DEV's are highly tallented people and that becuase of this their time is in great demand. I suspect comunication is becoming a bottle-neck and that with a properly organised de-centralised structure we could get more done. There is a lot of stuff that could be done that wouldn't need somebody like Ge personally, at least not beyond the occasional check for coherency. We do need quality control but quallity control is the one thing we've proven to be very good at de-centralising. We've got more senior users that will work together to hunt down more complicated issues and we've got a steady influx of enthousiastic new users that have turned out to be great at pointing out some things are under-documented. IMHO, Kas.

4 12

Seasonal greetings
by Kassen 24 Dec '08

24 Dec '08

^ / \ | | Merry ChucKmas to all and onwards to a good new year. Here's to another year of exciting new features to explore and fascinating new bugs to hunt for! Special thanks to the DEV's for putting them there in the past year; we've seen some especially interesting examples of both (I mean that; I enjoy both, honestly). Yours, Kas.

1 0

Porting Chuck on iPhone
by Ganesh Pisal 24 Dec '08

24 Dec '08

Hi, I have source code of Chuck. I want to port the code for iPhone platform. 1. How can I do same? 2. Is there any makefile available for iPhone platform? 3. Can I change makefile of Mac platform to work on iPhone platform? 4. Is there any sample iPhone application which uses Chuck? Regards, Ganesh Pisal Vavni Inc

1 0

Horrble noise bug?
by Les Hall 22 Dec '08

22 Dec '08

Hi folks, I'm working with some guitarists who are using my Guitar Zero practice program, and one of them reports the following problem: Hi Inventor I just tried the new version and the letters work perfectly on the start screen. Congratulations! ;D However, when I tested it I didn't actually connect the microphone, just checked the select game screen and [b]every time[/b] after I close miniAudicle my computer speakers + headphones just make a horrible buzzing noise and I have to restart the PC. Any ideas? A Is this a known bug? The user is running Windows XP. Any help or ideas would be appreciated, thanks. Les (Inventor)

2 1

LiSa.track() and .rampDown() (BUG)
by Kassen 22 Dec '08

22 Dec '08

Fellow ChucKists, Dear Dan. It seems like LiSa is ignoring .rampDown() while in .track(1) mode and .rampUp() becomes equivalent to .play(1). Consider the following example, this should generate a tone that fades in over the course of a second, then fades out. Instead we get a extended test-tone and no fades at all; //-------------8<-------------------- //boring test-tone recording SawOsc s => LiSa l => dac; second => l.duration; 1=> l.record; l.duration() => now; 0=> l.record; s=<l; //boring tracking signal Phasor p => l; second => p.period; 1 => l.track; //issue starts here second => l.rampUp; second => now; second => l.rampDown; hour => now; //-----------8<--------------------------- I believe that this isn't the intended behaviour; for one thing the relevant examples also use .rampDown() in combination with .track(), mysteriously there too the ramps don't work. Likely ramping in combination with track() got broken in a update since these examples were written, that would probably help narrow down the search for the nature of the issue. Then again; this could be a artefact of .track() being intended for single voice usage (I believe this was mentioned) and the ramps being functions of voices? I'll add this to the WiKi once it's been established that this is indeed a bug and not intended behaviour. Yours, Kas.

1 0

Issues when using several inputs on Motu Ultralite/OSX setup
by Stefan Blixt 21 Dec '08

21 Dec '08

I made a thread about this issue here: http://electro-music.com/forum/viewtopic.php?t=31032 . Kassen suggested that I send an email here, thinking that this might require some insight into RTAudio (not sure myself what it is). My Motu Ultralite runs ChucK applications perfectly, as long as I don't bother configuring audio channels, making do with having sound output only coming at the main outputs, and sound input from the MacBook Pro's built-in input or microphone. The problems start when I try to route to other outputs or want to use the Ultralite's inputs. After a bit of trial-and-error, I managed to get ChucK to do what I want to do (more or less) by using this command line to start the program: chuck --adc4 --in8 --out8 test.ck Here's the test code I have been using: adc.chan(6) => dac.chan(0); adc.chan(7) => dac.chan(1); while (true) { 1::day => now; } This will route audio from inputs 7 and 8 to outputs 1 and 2 (not the main outputs - if I want to hear the sound from the ChucK app I need to physically connect the 1 and 2 output to another input on the sound interface). A curious thing here is that if I start like this instead: chuck --adc4 --in8 --out6 test.ck // 6 outputs instead of 8 I get a mangled sound (sounding a bit like a sample rate or bandwidth mismatch - check the sound sample that I attached at the electro-music.comthread), and rather than just coming out of outputs 1 and 2 (as they do when I use the previous command line), the sound appears at all eight analog outputs on the Ultralite (according to the hardware meters on the Motu). If I try --out4 I get sound on outputs 1,2,,5,6,7, and 8. Another thing: if I leave out the output option altogether (i.e. take away "--out8"), I get a mangled sound as before, but only on the main output. I've also seen stuff like getting sound on every second output (1,3,5,7) for some option, though I can't seem to reproduce that now. I think I can work with what happens on my first example, but I'm still a bit curious as to what is going on with these options, and why --out6 causes the sound to behave radically different from --out8. I've checked my drivers - the Ultralite firmware is up to date and I think the OSX drivers are too. I'm running ChucK 1.2.1.2. I might have to leave my Motu for a week, so i might not be able to test stuff right away, if anyone comes up with something. /Stefan -- Release me, insect, or I will destroy the Cosmos!

2 1