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

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

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