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

Guitar Zero
by Les Hall 09 Jan '09

09 Jan '09

Hello fellow ChucKists! I may have spoken about Guitar Zero on the list before. The program is an interactive ChucK program for practicing guitar. I have made major updates to it, so if you are interested you can get the source here: http://www.freedomodds.com/music/chuck/GuitarZeroText31.ck The way it works is that first you get a menu with a little bit of fun ASCII art on it, and you select an option that will determine what quiz game you get. Let's say you choose random notes. Guitar Zero will print a guitar fretboard with the notes labeled and one of those notes will be highlighted with a box of text. You play that note and Guitar Zero will actually recognize it using comb filters made with the magic of ChucK! If you play the right note Guitar Zero beeps and you get another note. The program keeps track of how fast you play, then at some point you type spacebar or "z" to exit and you get an exit screen with a performance summary. I should also mention that Guitar Zero accepts input from the line-in jack or from a soundcard. The microphone does not work all that well in testing. I am testing this program with some forum members of the www.justinguitar.com community. JustinGuitar is a site that offers free guitar lessons via youtube video, and really good ones too, all done by a guy named Justin in Australia. He accepts donations and that enables him to expand the site, offering 100 free videos and now he travels the world playing and teaching guitar. Enough about that. Anyway, the test users are international and the main problem they have with ChucK and Guitar Zero is the keyboard. It seems that international keyboards such as a British or Belgian or German keyboard are handled improperly by ChucK and they can't use the menu options properly. I am writing about that little problem so that maybe the DEV team will notice and perhaps look into it (hah, as if they were not busy already). Anyway, it's a minor issue because if I recall correctly from Ge's holiday email, ChucK will soon have... *** CROSS PLATFORM MAUI **** and also *** FILE I/O *** Wow! That is amazing news, as it is just the thing for Guitar Zero which is turning into it's own little application for guitarists. I just exchanged some forum messages with one of the forum admins and he has suggested creating some sort of abstraction layer in which chord construction can be done and also in which scales can be represented, among other guitarish things. I feel that file I/O will greatly enhance Guitar Zero, enabling input files that store such an abstraction layer without having to embed it in the code. Also Guitar Zero can play songs, or rather prompt the user to play songs, and these songs can be stored in text files. In addition it is desirable to store calibration data for each user's guitar so that proper signal recognition can occur. So here's three cheers to Ge and his code-wizard DEV team members for providing all of us with such a great upgrade to ChucK. OK, I'll close now, I've rambled on enough. Happy new year everyone and let's make this year a good one for music lovers everywhere! Les (Inventor)

2 1

Status on running shreds?
by Arjan Scherpenisse 07 Jan '09

07 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, I'm new here, and not so much into audio programming (yet), but I'm interested in ChucK from a software perspective. I'm trying to code a little "live coding" app (python+gtk+glade), much like the miniAudicle, but interfacing with ChucK through shell commands (like chuck-mode for emacs). So I wondered whether it's possible to get information on the running chuck process. In the simplest form, I would like to get the output of the "chuck --status" command. That command now lets the VM write on its stdout; not on the stdout of the calling process. Can somebody point me in the right direction? Thanks, Arjan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklhOLUACgkQigE4AbflYeoMagCfeqLMlrG6hXKFmfV2IuuPkauD HsgAn0RvcVJnjHcXHJHoOCv7sy5Rj+nP =spEn -----END PGP SIGNATURE-----

3 5

Problem with reverb and multi-voices
by Andrew C. Smith 05 Jan '09

05 Jan '09

I'm sure there's an easy way to do this, but I'm out of practice. Trying to warm myself back up before the Max5-compatible chuck~ is ready. I'll attach my code, but the basic problem is that if I hit the SMS twice, the smack spork will change the reverb and gain levels for everything, so that I can't layer voices with different settings. Is there a better way to organize this? Probably. The y-hit is supposed to change the g.gain, while the x-hit changes the rev.mix. Just an experiment with the SMS to impress my friends (they're easily impressed). Thanks all, Andrew ps: is it possible to switch subscription from digest to regular list-serve? Thanks.

4 6

Re: [chuck-users] UGen based Pitch tracking demo (with BUG?)
by Kassen 02 Jan '09

02 Jan '09

Fellow ChucKists, A new year (at least on the Roman calendar). Us ChucKists should feel especially good about this one as the Roman calendar had a leap second this year; I don't think the rest of the universe is as strongly timed as we are. Anyway, a brand new year and brand new bugs, starting with one of mine. Consider this fragment; > //========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(); > } > > Note that the second version shouldn't have the "dur length" parameter, it should be overloaded to get the averaging period, which might be useful at times, for example to make sure that this period isn't too short compared to the frequency we are getting. My fault; I was too hasty in my enthusiasm. Considder updating your files if you added this to a collection of useful code fragments. More generally; this means that we can apparently have overloaded functions that take the same argument(s) within the same scope. I don't think that's correct behaviour; this could lead to a lot of confusion and I can't think of a single instance where it would be beneficial. To make it more clear without any class being involved; //-------------- //this will parse and run; fun int foo (int bar) { return false; } //this one is just silly, in fact it won't even be called, the top one has priority fun int foo (int bar) { return true; } //------------- Now; "powertools can maim" and I don't mean to blame ChucK for a silly mistake that *I* made but do we really have a need to be able to have those two functions within the same scope? Can anybody think of a single instance where this could be useful at all? There are/were other instances where the overloading of functions wasn't propperly checked (particularly with regard to return types) which could/can lead to crashes. I feel it should be considdered to check for this as well when checks for that situation are added to the parser, even if this type of thing doesn't crash as such. Yours, Kas.

2 2

fread function
by Dexter J. Doyle 02 Jan '09

02 Jan '09

Hey list, I'm pretty new to programming in ChucK. I'm trying to figure out what would be the easiest way to implement C's fread function in ChucK? Thanks, Dexter

2 1

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