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

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

03 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 29 Dec '08

29 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

December 20th, 2008 :: Apero codelab in Nantes
by emoc * 17 Dec '08

17 Dec '08

Hi Chuckers, If you're interested in having us play audio recordings of your chuck music, drop us a line at apero(a)crealab.info with a link to files we can download, and a second line mentioning the authors and license of the documents that should appear. Supported filetypes and codecs: everything but WMV, WMA, Real and things too proprietary. You can post links here too! All the best emoc ===December 20th, 2008 :: APERO CODELAB 01 in Nantes (Fr)=== * chat, mix & performances * free entrance Saturday December 20th, 2008 from 7:00PM until 11:00PM at the Canotier, 21 quai de Versailles, in Nantes (France) contact : +33 (0)2 40 16 86 78 – info(a)crealab.info L'apéro Codelab 01 is a meeting dedicated to experiments in the audio-visual and musical fields which use programming languages or electronic experimentation, in the spirit of open source. This meeting is organized and moderated by the members of the Crealab network <Apo33 /PiNG / Lolab /la Fabrique du Libre /Ecos>. who take the occasion to invite Emoc, founder of the http://www.codelab.fr forum, a resource in the french-speaking online world on the topic experimental practices. Program * introduction to codelab.fr, short presentation of books such as "Making things talk" by Tom igoe, "Computer Music with examples in SuperCollider 3", "Designing sound" by Andy Farnell) and artworks ("Reflet" by Thomas Otra, "Topodio", by Dominique Leroy & Jean-François Rolez / la fabrique du libre) * Puredata news: the Pdmtl abstractions, Pdpédia is back... * performances by Wilfried Nail, Gary Glitcher * mix of images & sounds from the communauty ! open to anyone ! really ! even if you can't blatter in French...

1 0

I Put A Physics Engine In Chuck
by Zed A. Shaw 15 Dec '08

15 Dec '08

Well, I'm having fun with chuck and plan on using it for a little music like project. In order to make the project work though, I needed a physics engine in chuck, so I put one in there: http://rafb.net/p/SRbR9A13.html That's a sample from my hack in progress. I just put in Box2D_Lite for now to get the idea working, but so far it's pretty nice. Right now all I've got is a Physics UGen that lets you put in an observer and a sound source, and then set their movement. It will then determine the distance and adjust the gain. Next up is pan for left/right of observer, colliding events, and maybe a doppler effect pitch shift based on velocity. -- Zed A. Shaw http://freehackersunion.org/

3 2

Organizing Chuck Projects
by mike clemow 15 Dec '08

15 Dec '08

Hi Chuckers, Just thought I'd plumb the depths of your collective brains (as a procrastination break) to see how you all organize larger coding projects in Chuck. I have a bunch of public classes in files and an init.ck file that Machine.add's them all in the proper order. DIY Chuck class library. It's kind of hackish, though, and I want to write a Chuck session manager application. Is that a dumb idea? How do you all organize your code? Struggling through finals, Mike -- http://michaelclemow.com http://semiotech.org

4 4

Three cheers ( and one small frown) for Dan
by Kassen 13 Dec '08

13 Dec '08

Dear list (and Dan!) LiSa.track() is brilliant! ( See; http://wiki.cs.princeton.edu/index.php/LiSa_examples ). In the past days I've had a renewed enthusiasm for experimenting with LiSa to try to emulate turntable scratches and now turntableist techniques/gestures as well. (You can read reports and see videos excerpts of the relevant sessions here; http://steim.org/jamboree08/ there is a interesting forum starting here; http://forum.itchymuzik.com/index.php ). LiSa.track() seems especially well suited to emulating platter inertia; if I understand it all correctly a simple LPF over the tracking signal will give us most of this "for free". Brilliant stuff, loads of cheap fun with breakbeats. This will be very useful indeed to many people, I imagine. But... unless I'm completely mistaken this was nowhere to be seen in the release notes. I knew it was comming, but I had no idea it was here already. Yours, Kas. PS; //=========================== //"abstract turntableism" by Kas, hacked up in a few minutes //Remixing strongly encouraged //add your own break, tweaking may be needed SndBuf b => LiSa l => Envelope cut => dac; //add your own "break2.wav" => b.read; b.samples()::samp => l.duration; 1 => l.record; l.duration() => now; 0 => l.record; b=<l; Step unity => Envelope e => LPF f => l; //inertia (sort of) 3 => f.freq; unity.next(true); 1 => l.track; 1 => l.play; .125::l.duration() => e.duration; fun void fade() { 1=> int times; while(1) { Std.rand2(2,6) => times; (1.0/times)::e.duration() => cut.duration; repeat (times) { !(cut.value() $ int) => cut.target; cut.duration() => now; } } } spork ~fade(); 1=> int direction; while(1) { -1 *=> direction; (.125 * Std.rand2(direction, 4* direction) + e.target()) % 1 => e.target; e.duration() => now; }

1 0

Dec10 Steim, Amsterdam (NL), presentation
by Kassen 11 Dec '08

11 Dec '08

Dear list, People in The Netherlands may be interested in my presentation at Steim in Amsterdam on December 10 as part of Steim's "Micro jamboree" http://steim.org/jamboree08/ Steim is a organisation that develops, promotes, etc, new interfaces for electronic music. I'll be talking about my sequencer (for writing house using a joystick), about ChucK, my perspectives on improvisation and the use of game devices, illustrating details by improvising some music. There should be space for debate and questions as well. Some of the other sessions may be of interest to people on this list as well. I gather that these sessions are free though reservations are necessary. ( info here; http://steim.org/jamboree08/?page_id=35 ) In case nobody in NL is around it may at least be good to know that STEIM is interested in hearing about ChucK. STEIM is a rather unique institute and I'm very happy the council reversed it's decision and STEIM will continue to get funding; I'm not aware of any other institute that is exclusively dedicated to new interfaces for improvised electronic music. Yours, Kas.

2 3

formatting string
by Beinan Li 09 Dec '08

09 Dec '08

Dear ChucKers, I couldn't find a thorough recipe of ChucK's string in the manual. Could I format a string as I do with sprintf in C or Matlab? If so, how? Thanks. Beinan

2 1

get whole sndbuf content as uana
by werteplus＠gmail.com 09 Dec '08

09 Dec '08

hey list! i'm trying to abuse chuck for non-realtime tasks. i want to fft a wav file, do some freaky stuff, ifft it again and save the result as wav to the disk + play it. problem with this is that fft seems to only accept incoming samples being chucked realtime. any chance to upchuck sndbuf's whole content to a uana like fft? thanks, fabb

1 0

static strings
by Beinan Li 08 Dec '08

08 Dec '08

Dear ChucKers, 1st of all I'm a newbie to ChucK (Many thanks to Steve who brought me here). I bumped into a problem regarding static strings, which would really not have been in my way if I designed it another way, but I still feel it important enough. Here is the story. I wanted to create a function in a stand-alone .ck module to load my instrument samples from disk. So I designed my loader class in *instr_loader.ck* like this: > public class Instr_loader > { > "path/to/instrument" => static string m_p_instr; > > fun static string get_instr {return m_p_instr;} > } > For some reason I just wanted to test the static flavor of ChucK, there is really no reason to use a static member here I must confess. Then my client code *main.ck* looks like this: > Instr_loader.get_instr() => string path_instr; > when I run both .ck's, I will get: > [Instr_loader.ck]:line(3): cannot declare static non-primitive objects > (yet)... > [Instr_loader.ck]:line(3): ...(hint: declare as ref (@) & initialize > outside for now) > Then I change the code with the reference to: > "some/path" => static string @ m_p_loop > Then I run > chuck Instr_loader.ck main.ck > and get this: [Instr_loader.ck]:line(3): cannot declare references (@) of primitive type > 'string'... > [Instr_loader.ck]:line(3): ...(primitive types: 'int', 'float', 'time', > 'dur') > So is there a reason why string is not part of primitive types? BTW: it works perfectly using string as normal class member. I'm just interested in this problem here. Thank you and hope ChucK will chuck it all up~! Beinan On Sun, Dec 7, 2008 at 8:09 PM, Stephen Sinclair <sinclair(a)music.mcgill.ca> wrote: > Yeah, but you have to make it a static function of a public class. > The class model in ChucK is still a little awkward, but public classes > can be instantiated in other files. Only one public class can be > defined per file! > > Steve > > > On Sun, Dec 7, 2008 at 7:51 PM, Beinan Li <li.beinan(a)gmail.com> wrote: >> Hi Steve, >> >> Should be a newbie question: >> In ChuCK, can you define a function in a single .ck file >> and call it from another .ck like in Matlab? >> >> Thanks. >> >> Beinan >> >> >> >

1 0

Re: [chuck-users] USB Accelerometer
by Les Hall 02 Dec '08

02 Dec '08

Hi again. Just to be clear, because I wasn't clear enough in my recent post, what I have is a prototype of the product. It is exactly like the version that Ultimarc will soon carry on their product line but at the moment the darn accelerometer chips are unavailable! Yep, we can't get the chips at this time. So they are on order. When the chips become available then the product will be added to the web page at a reasonable price. The link, www.ultimarc.com, and the sub-section on that page about the U-HID nano, describe the nano prior to having an accelerometer bolted onto it. I'll notify the list when the part becomes available and ready for purchase. Thanks, Les (Inventor)

1 0

USB Accelerometer
by Les Hall 02 Dec '08

02 Dec '08

Good news, friends! I have received a working prototype of the USB Accelerometer that I told you all about a couple of times in recent months, and initial testing indicates that it is working perfectly. This device is about the size of two postage stamps. It comes with a five-foot (I think?) USB cable and a small wire harness that attaches to a right-angle header. The header allows the device to be programmed to receive button and potentiometer inputs as well as slow Analog and Digital inputs. It can also drive LEDs, though ChucK does not drive joystick LEDs yet. Oh yes, and it looks like an ordinary joystick so the programming interface is joy-fully easy to do in ChucK. The accelerometer is the same ADXL330 that is in the WiiMote and the ADC has enough resolution to read it accurately down to the noise floor of the device, so it is plenty sensitive. Sounds like a commercial? Yeah, well I'm excited about it - this thingamajig is the product of several months of work. I had made all the plans to DIY such a beast when I approached the company Ultimarc and suggested they might want to add it to their product line. To my amazement, Andy at ultimarc said he'd like to do just that! I was so excited then, and now it's sitting on my desk awaiting further testing! If you want to get a feel for the device, you can look up the U-HID nano on the Ultimarc web site, which is www.ultimarc.com. Just click on U-HID and then look for the baby brother of the U-HID, the U-HID nano. Our product is the U-HID nano complete with expansion port and with an accelerometer squeezed onto the little board (well, a tiny bit bigger). You can also email Andy about it, his email address is andy(a)ultimarc.com. Just one more step forward on this fun and wild adventure that we call ChucK! Les (Inventor)

1 0

question about implementing a UANA
by Dexter J. Doyle 22 Nov '08

22 Nov '08

I've been working on implementing a pitch detector as a UANA in ChucK and I am basing it off code for a pitch detector that is written in C. I've been editing the file, uana_extract.cpp and wanted to see if there is a way to handle shorts and longs and their respective arrays since ChucK only has int and float. Dexter

1 0

Re: [chuck-users] Mixing associative with integer indexed arrays? (multiple BUGS)
by Kassen 22 Nov '08

22 Nov '08

Hi, Stephen! 2008/11/22 Stephen Sugden <glurgle(a)gmail.com> > Is it possible to mix both types of array keys? Yes... or at least it *should* be.... ;¬) > The code I below works fine until I try to access any elements of the > array, then I get an ArrayOutofBounds exception. I corrected the lack of a type for "melodies". Then I had a hard time with it, as it turns out that this; [ 0, 2, 4, 5, 7, 9, 11, 12 ] @=> int melodies[0]; crashes ChucK. That's a bug, and it's good that we accidentally found it but kindly try to avoid such confusion by making sure the code you send works as you described. Right, on to the business at hand; > <<< scales["just"][0] >>>; > > You can't print the contents of a array (which this refers to) in one swoop like this, I fear. If you'd like to do this you'd have to loop over the array, if they all need to be on the same line and the length of the array is dynamic I think you'll have to join all elements together in a string and print that. Let's look at a version that should work properly; //=========================== float scales[0][0][0]; [ 0, 2, 4, 5, 7, 9, 11, 12 ] @=> int melodies[]; [ [1.0, 1.0], [16.0, 15.0], [9.0, 8.0], [6.0, 5.0], [5.0, 4.0], [4.0, 3.0], [7.0,5.0], [3.0, 2.0], [8.0,5.0], [5.0, 3.0], [7.0, 4.0], [15.0, 8.0], [2.0, 1.0] ] @=> scales["just"]; float et[13][2]; for(0 => int i; i <= 12; ++i){ 1.0 => et[i][0]; Math.pow(2.0, i / 12.0) => et[i][1]; } et @=> scales["equalTempered"]; for(int n; n< scales["just"][0].cap(); n++) { //goes out of bound for n==0 already <<<scales["just"][0][n]>>>; } //================== So... that's a bug, yes, and clearing out the associative indexes in favour of ints makes it go away. Good catch! If you'd like; add it to the Wiki here; http://wiki.cs.princeton.edu/index.php/ChucK/Bugs/Release Yours, Kas.

2 2

Mixing associative with integer indexed arrays?
by Stephen Sugden 22 Nov '08

22 Nov '08

Is it possible to mix both types of array keys? The code I below works fine until I try to access any elements of the array, then I get an ArrayOutofBounds exception. The snippet is pretty short and I would hope it's self evident what I'm trying do with it. float scales[0][0][0]; [ 0, 2, 4, 5, 7, 9, 11, 12 ] @=> melodies[0]; [ [1.0, 1.0], [16.0, 15.0], [9.0, 8.0], [6.0, 5.0], [5.0, 4.0], [4.0, 3.0], [7.0,5.0], [3.0, 2.0], [8.0,5.0], [5.0, 3.0], [7.0, 4.0], [15.0, 8.0], [2.0, 1.0] ] @=> scales["just"]; float et[13][2]; for(0 => int i; i <= 12; ++i){ 1.0 => et[i][0]; Math.pow(2.0, i / 12.0) => et[i][1]; } et @=> scales["equalTempered"]; <<< scales["just"][0] >>>;

1 0

Bay Area Computer Music Technology Group
by Noah Thorp 19 Nov '08

19 Nov '08

Thank you to Pyramind for hosting the Bay Area Computer Music Technlogy Group this month. Our speakers will be Yale Professor Paul Hudak on Haskore (a functional programming audio library written in Haskell) and Smule CTO and Stanford Assistant Professor Ge Wang on iPhone audio applications (including Smule's #1 selling US iPhone app Ocarina). Hope to see some of you there. The details are below. Best, Noah Thorp Bay Area Computer Music Technology Group Organizer ------------------------------------------------- Bay Area Computer Music Technology Group (BArCMuT) Presentations Thursday, Nov 20th 2008 @ 7pm Pyramind, 832 Folsom, SF, CA Please RSVP here for event sign in: http://www.barcmut.org Haskore II: from Signals to Symphonies Paul Hudak Haskore is a computer music library written in Haskell. As such it is not a new language, although it has the "look and feel" of a special- purpose language. It is the only computer music programming environment based on a purely functional programming model. In the context of Yale's new Computing and the Arts initiative, Haskore is being re-designed and enhanced in a number of ways. In this talk we discuss the design rationale for Haskore II, describe its basic functionality, and highlight some of its more innovative features: a vertical language design (from signals to symphonies), a separation between structure and interpretation (form and function), its graphical music interface (GMI), real-time sound synthesis, and its use of functional reactive programming (FRP) in interactive music applications. Introducing Smule: Interactive Sonic Media on the iPhone Ge Wang We present our adventure (so far) with Smule, a startup company exploring interactive sonic media on the iPhone (whatever that might mean). Co-founded in 2008 by CEO Jeff Smith, CTO Ge Wang, along with several Stanford and Princeton professors and students, Smule serves as a unique platform for research and development combining the state- of-the-art in computer music research with the potential to bring its visions to a wide population. In this presentation, we not only showcase the end products (Sonic Lighter, Sonic Boom, Sonic Vox, and the #1 bestselling Ocarina), but also discuss the roles sound and interaction take on in creating them. Smule is exploring how to change the way people think, work, and play through sound and music. Smule/Ocarina: http://www.smule.com/ http://ocarina.smule.com/ Also, after the BArCMuT presentations Peter Nyboer will be debuting his new video and hand drawing sound interface at the Luggage Store Music by The Eyeful event. In his words: "My newest creation combines the joys of music improv, mathematics lecturing, simple concepts of sound synthesis, and mid-(last)-century notions of electronic music scores. My instrument is a pen-and-paper, channeled through a computer." Peter will perform a little after 9pm here: http://www.luggagestoregallery.org , 1007 Market St. (@ 6th St), SF, CA. BIOS --- PAUL HUDAK was one of the principal organizers of the "Haskell Committee," an international group of computer scientists who designed Haskell. He is co-Editor-in-Chief for the Journal of Functional Programming, Editor for the Journal of Higher-Order and Symbolic Logic, and charter member of IFIP Working Group 2.8 on Functional Programming. He is a recipient of an NSF Presidential Young Investigator Award and an IBM Faculty Development Award, and in 2004 was elected as a Fellow of the ACM. Prof. Hudak was also Chairman of the Department of Computer Science at Yale from 1999 to 2005. Paul is also the author of The Haskell School of Expression: Learning Functional Programming through Multimedia, Cambridge University Press, New York, 2000. For more information about Paul and projects he is involved in visit these links: http://cs-www.cs.yale.edu/homes/hudak-paul/ http://www.cs.yale.edu/people/hudak.html GE WANG is currently an assistant professor at Stanford University in the Center for Computer Research in Music and Acoustics (CCRMA). His research interests include interactive software systems (of all sizes) for computer music, programming languages, sound synthesis and analysis, music information retrieval, new performance ensembles (e.g., laptop orchestra) and paradigms (e.g., live coding), visualization, interfaces for human-computer interaction, interactive audio over networks, and methodologies for education at the intersection of computer science and music. Ge is the chief architect and co-creator of the ChucK audio programming language, and the Audicle environment. He was a founding developer and co-director of the Princeton Laptop Orchestra (PLOrk), the founder and director of the Stanford Laptop Orchestra (SLOrk). Ge composes and performs via various electro-acoustic and computer- mediated means. Additionally, Ge is the Co-founder and CTO of Smule (a.k.a. SonicMule, Inc.), a startup company exploring interactive sonic media for the iPhone. Smule serves as a unique platform for research and development combining the state-of-the-art in computer music research with the potential to bring its visions to a wide population. Ge is the lead designer of Smule's Ocarina (currently the paid #1 iPhone application in the U.S. as well as in 20 other stores around the world). Ge Wang: http://ccrma.stanford.edu/~ge/

1 0