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

new [chuck~] object available
by Brad Garton 19 Jan '09

19 Jan '09

Everyone -- Version 1.4 (MaxMSP 4.x) and 1.5 (Max5) of the [chuck~] Max/MSP object are available for free download: http://music.columbia.edu/~brad/chuck~/ for Macintosh OS X (10.4 and 10.5). The new [chuck~] object is up-to-date with the latest (v 1.2.1.2) release of the ChucK language, including the LiSa live-sampling unit generators and the unit-analysis generators in the 1.2.1.2 package. [chuck~] imbeds the ChucK music-programming language in Max/MSP, bringing a sophisticated set of synthesis and signal-processing tools into the Max/MSP environment. [chuck~] also features an advanced timing and scheduling system in addition to a functional-style programming interface for algorithmic operations. Full source for the object and the language are also on-line. No Windows XP version is available at present -- sorry! This is a fun object -- enjoy it! For more information about ChucK, visit the ChucK web page: http://chuck.cs.princeton.edu/ Brad Garton, Director Columbia University Computer Music Center http://music.columbia.edu/~brad

1 0

live coding lab == 27/02 > 01/03 == ghent/belgium
by Bram de Jong 14 Jan '09

14 Jan '09

(appologies for cross-posting in advance) Hello live coders, = summary = live coding lab+battle at resonance ghent :: call to arms+collaboration 2009, February 27 -> march 1 location: espace ladda ( http://www.espaceladda.be/ ) and art center vooruit ( http://www.vooruit.be/ ), ghent, belgium = /summary= My name is Bram de Jong (you might know me from freesound.org / smartelectronix.com / musicdsp.org) and I've been appointed as one of the chief-noisemakers for the upcoming Resonance Festival ( http://www.resonanceghent.be ) in Ghent - Belgium. In particular, I'm responsible for the live coding workshop which will take place in the "espace ladda" right next to the artcenter. There will be 3 days of intense workshopping, collaboration, battles, but the format will be completely open. Space to seat about 10-13, 2 vid projectors, big mixing desk, enough audio cables to strangle a cabbage (I'm a cat lover), headphone splitters + headphones so people can listen in on you / spy / steal your best ideas in true open source sense. On Sunday afternoon, we shall all chill out in the Café and get some proper live coding wars onto the large speakers and projection screen in a relaxed/energetic/stressed battle environment, powered by plenty of Belgian Beers. Who is invited: everyone who does live graphics+coding or live audio, if you want to join, send an email to bram(a)resonanceghent.be with some youtube-y examples of what you do, some website to look at, some art, whatever you can throw at us. What is included: we offer the space and for some of you we will be able to (help?) pay the voyage. Sleeping places will be cozy and personal (read: in someones house) rather than expensive and hotel-based. Couleur locale powered. Once we get all proposals/.. we will see who we can help. Our budget is very limited. Oooh, and we also give everyone who comes play a free entrance to the festival (Machinefabriek, Eavesdropper, Alva Noto, Move D & Benjamin Brunn, Claro Intelecto & Andy Stott, Peter Van Hoesen, Mokira / Andreas Tilliander, Echospace). What would we like you to bring: your laptop and anything you think is cool to tinker with. If you have some circuitbent cheezegraters you think sound cool, bring'm and add them to your soft/hard tweaking! We'd like you to bring crazy things. Yes. The crazier the better. Note: if you live closer (uk, de, nl, fr), chances will be greater we can pay your flight/train/bus! much love and a happy ny. - Bram -- http://www.freesound.org http://www.smartelectronix.com http://www.musicdsp.org

1 0

Re: [chuck-users] Guitar Lab
by Les Hall 11 Jan '09

11 Jan '09

Kassen, My test user said that message.ascii worked great! Issue resolved. Les

2 1

Re: [chuck-users] Guitar Zero
by Les Hall 10 Jan '09

10 Jan '09

Kassen, OK, I coded it up with message.ascii. Now I see what you mean about this being well thought-out and not a problem. message.ascii works fine for me, I hope it also works for my test users. We will find out in a while. Les

1 0

Re: [chuck-users] Guitar Zero
by Les Hall 10 Jan '09

10 Jan '09

Hi, me again, Here is what my test user had to say about the keyboard: Again, the letters and numbers weren't working properly. (I do have a standard American Qwerty keyboard.) No letters work at all, neither does the space bar, and the numbers are 2 off of what they say to be. In other words, 1 and 2 have no response and hitting 3 brings up the minor pentatonic scale game, and so on and so fourth all the way up to 0 and -. Not sure why this would happen, but at least it worked. This is typical of what I get from users trying out Guitar Zero, but it's always different. Not sure what to do, try message.ascii()? Les (Inventor)

2 1

Re: [chuck-users] Guitar Zero
by Les Hall 10 Jan '09

10 Jan '09

Hi Kassen, Thanks for your comments! You wrote: I hope that either clarifies the situation or will encourage you to explain what I missed so far, maybe German keyboards do terrible things, like sending different signals for the cursor keys; I never tried one. Actually, yes I do have such an example, specifically the number keys (the ones above the keyboard). On British and Belgian keyboards the number keys return completely different message.which() codes. The Belgian keyboard is particularly tricky as it's number keys are all replaced with special French characters. So when I made a numeric menu, my Belgian friend couldn't work the program. He eventually played around with it and found that some of the letter keys gave numeric codes, and gained access into the program that way. Also the British numbers didn't work, and I haven't had a German user yet but I expect a similar problem. So I made number / letter combinations for the menu like 1 or a, 2 or b, 3 or c, etc. and that helped a lot, but still there are problems. When we get cross-platform MAUI, I'll make the program graphical again and that will solve the keyboard issue, but I really do think it is something that is not quite kosher. I mean, after all we want our ChucK programs to work in the UK and Belgium, right? :) Maybe I should use message.ascii(), do you think that would solve it? Maybe that's *why* message.ascii() exists? Regards, Les

2 1

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