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

Re: [chuck-users] The ChucK Show
by Les Hall 10 May '09

10 May '09

Hi folks, We had a really big big shew last week and we're up to show 7 now! Sunshine was a blast as always and her psychotic dog Ginger interrupted with barking as usual, haha! Last week we featured wmonk and the one and only Ge Wang as our two Chuckists of note! Will you be next? We need material so post away with code or mp3's, thanks! You can get recordings here: http://electro-music.com/radio/archives/ Peace Out! Les (Inventor)

1 0

Array out of bounds.... error usability
by Kassen 08 May '09

08 May '09

Fellow ChucKists, I have a ArrayOutOfBounds error and I'm quite sure that's one of my mistakes, not a ChucK one. This will require a bit of searching as I have rather a lot of arrays here and rather a lot of different things are done with them. Let's have a look at this; ArrayOutOfBounds: in shred[id=2:tr8or.ck], PC=[3565], index=[4] Ok, so it's a array that gets defined in my main shred and it's one that's 4 or less elements in size. That narrows it down considerably but we're not there yet. Now, I have the feeling that ChucK is trying to tell me something with the "PC=[3565]" but that bit is quite useless to me as I have no idea what it means. Questions; What does the PC bit mean? How is it useful? Can we consider ways of making it more useful? Yours, Kas.

4 6

other ways to live-code with time
by Tom Lieber 08 May '09

08 May '09

impromptu is a live-coding environment for OS X that looks very interesting, definitely something I need to try out once I've escaped the clutches of my end-of-year work. http://impromptu.moso.com.au/ I thought I'd bring it up not only because it's interesting, but because its tutorial on "time" contrasts impromptu's asynchronous model with ChucK's synchronous one: in impromptu, time passes while your code is running. You can read the tutorial here: http://impromptu.moso.com.au/tutorials/time.html Just think... you could load a WAV file without hanging the VM! It's interesting to see what you get when you trade one complication (waiting on slow shreds) for another (having "now" change beneath your feet). Here are some, from the tutorial: "There are a couple of gotcha's to keep in mind when doing schedule and forget programming. The first thing to keep in mind is that (now) is an airy fairy thing. In the example below the two notes may be scheduled to play on the same sample - but then again, they may not - (now) may have moved forward in time between the two calls (even if evaluated at the same time). (play-note (now) piano 60 80 *second*) (play-note (now) piano 72 80 *second*) "Often this lack of precision is fine (i.e. too small a change to be noticeable) but where absolute accuracy is required a time variable should be used. (let ((time (now))) (play-note time piano 60 80 *second*) (play-note time piano 72 80 *second*)) "This inaccuracy becomes more of an issue when amplified over time such as using (now) inside a recursive callback loop. We can avoid the problem by precisely incrementing a time value between each recursive callback (note that any arguments required by the function being called back must also be passed to callback). ;This is bad (define loop (lambda () (play-note (now) piano 60 80 *second*) (callback (+ (now) *second*) 'loop))) (loop) ;This is good (precise time arg is now incremented each recursion) (define loop (lambda (time) (play-note time piano 60 80 *second* ) (callback (+ time *second*) 'loop (+ time *second*)))) (loop (now)) "The second major gotcha in recursive callback loops is that (now) is now. Code requires some time to execute. If you are executing a call to evaluate a note (now) by the time the code is evaluated it will already be late. You should always try to schedule your code execution ahead of the scheduled time of your tasks. ;This is best (callback happens 4100 samples earlier than new time) (define loop (lambda (time) (play-note time piano 60 80 1.0) (callback (+ time 40000) 'loop (+ time 44100)))) (loop (now)) "In the this-is-good version of loop the time sent as an argument to loop is exactly the same time as the scheduled callback time. The problem with this is that the next note needs to be scheduled at exactly the same time that the function is called. The note will always be late. The this-is-best version schedules the callback just ahead of the time that we want to schedule the note. This gives us 4100 samples to execute the code to schedule the note before the note is required to sound." The last sentence reminds me of the thread a while back about benchmarking UGens. :) -- Tom Lieber http://AllTom.com/

7 20

Re: [chuck-users] The ChucK Show
by Les Hall 07 May '09

07 May '09

When do you need it by, Les? I have to put together something for my thesis presentation on Friday. The project involves data-sonification and ChucK is my weapon of choice. _mike mike, Anytime is fine, i'll just include it in the next show whenever I get it. Cheers, Les (Inventor)

1 0

WvIn on osx and linux
by jo 07 May '09

07 May '09

Hi, have been using WvIn for some while as a workaround to read a data file into chuck (this was suggested by someone in an earlier post), e.g. WvIn w => blackhole; "data.wav" => w.path; float n; repeat(20) { 1::samp => now; w.last() => n; <<< n >>>; } This works fine on my mac. However, when I try to do this in linux, it fails, sort of. The first value is the same as on os x, but then they deviate, not completely, but significantly (more than 10%), so it can't be a simple rounding error. I'm relatively sure that the values on the mac are correct because I write the data to the wav file myself. It's not obvious to me why the reading of any .wav file (using last()) should produce different values on different operating systems, but they do on my computers! Does anyone know what could be going on here? thanks, jo

3 8

Re: [chuck-users] The ChucK Show
by Les Hall 05 May '09

05 May '09

Kas, moved Antimon to the intermediates section. Sure, I'll post the code to the forum. Rob, Source code would definitely be appreciated, that way folks can learn from your code and rip it up if they want to, lol! Just post it to the forum or the list or email it to me, any way will do fine. Oh, yes, go to the ChucK site and click on wiki to get to the wiki. Yeah! Les (Inventor)

3 2

The ChucK Show
by Les Hall 05 May '09

05 May '09

Hi folks, The theme for the seventh ChucK show is "from newbie to expert". We will feature ChucK code written by newbies, intermediates, and experts. The newbies have been sending me some really awesome code, and there is some intermediate code plus lots of expert mp3's from the wiki. Here is the outline of next week's show, so far: Beginners remder-3c: kijjaz's friend in Thailand, 3rd ChucK program ever! RitualMusicfromBetelgeuse: Slinky's second ChucK program! telstar3: telstarmagickistferarri, a member of our community WindAntimon: intended for the "winds of change show" wmonk: ChucKist of the week: 20 year old college student programming since 10 years old, so 10 years of experience inspired by the show, Linux user, set up ChucK in the chatroom within 15 minutes had a program: wmonk.mp3 Then shortly after that wmonk2.mp3 Fast Learner!!! Intermediates Guitar Lab Rock3: me on ChucK Guitar Lab stooges: by Rob, 3 stooges do Zappa, lol Experts Electrindian: Michael Hammond from 2005 for assignment 2 of PLOrk HackChuck: by Perry Cook for Ge Wang's PhD graduation marco polo: R. W. Enoch from 2005 for assignment 2 of PLOrk otfc2005x: Peerry Cook and Ge Wang, Performed on the fly to an audience sounds like a robot being born and then youth and then adulthood Smooth Criminal: Tribute to Michael Jackson by Perry Cook WindChimes: by kijjaz, mistakenly not played on winds of change show This is fine, and will fill up the hour, but after this the outlook appears kind of light for material. I'd like to know what the links are for PLOrk, SLOrk, and other ChucKian organizations where I can shamelessly rip code or mp3's from to keep the show interesting and novel. There's a lot of ChucK activity out there and I want to tap into it, so could someone please link me up? Thanks, Les (Inventor)

3 2

OSC on iPhone/iPod touch
by Mark Cerqueira 04 May '09

04 May '09

I was perusing the App Store and found this app under "Staff Favorites" TouchOSC is an iPhone / iPod Touch application that lets you send and receive Open Sound Control messages over a Wi-Fi network using the UDP protocol. http://hexler.net/software/touchosc Has anyone tried this app with OSC ChucK? Perhaps if this app proves to be useful, we can convince Dan to get us all iPods for PLOrk- related-business.... iPLOrk? Best, Mark

4 4

Amusing ditty for the day
by Robert Poor 04 May '09

04 May '09

I was experimenting with some ChucK-ian control structures, and, well, er, um, heh. Ahem. Think of it as "The Three Stooges play Zappa's interpretation of Edgard Varese". For two minutes of amusement only: http://homepage.mac.com/rpoor/Music/stooges.mp3 ...now they'll *never* let me into La Sorbonne... - Rob

1 0

To cheer us up on a rainy day, a Michael Jackson Tribute Hack!
by Perry R Cook 04 May '09

04 May '09

http://www.cs.princeton.edu/~prc/SmoothCriminal.ck

2 1

Re: [chuck-users] The ChucK Show
by Les Hall 03 May '09

03 May '09

Hey folks, The last two weeks of The ChucK Show went well. The whole Paranoid Schizophrenia album went over just fine and yesterday we did a two hour show to cover for Shane who's power went out. Kassen showed up and had fun in the chatroom and dtoliaferro was there too. kewl. The link for recordings has changed, here is the new semi-permanent link: http://electro-music.com/radio/archives/ Hope you can give a listen to Sunshine and myself.... Les (Inventor)

2 1

Re: [chuck-users] dbtopow(), dbtorms(), powtodb(), powtorms() off by 100 db (Robert Poor)
by Perry R Cook 03 May '09

03 May '09

Oh yea, that too :-) Thanx Adam. PRC ----- "Perry R Cook" <prc(a)cs.princeton.edu> wrote: > dB just implies 20log_10. A reference must be selected. > > The most common are dBV (1 volt = 0dB), dBm (0dB = 1 milliwatt into > 600 ohms), and dBSPL (watts relative to threshold of hearing at 0dB). > > I suspect that the implementers of this were thinking about > the approximate 96dB of 16 bit audio, and the +/-1.0 float > recommended max range of STK. Thus a range of 0.00001=0dB > to 1.0=100dB resulted. Easy to change to any reference by > just subtracting/adding/multiplying/dividing by a constant. > > PRC

3 3

Re: [chuck-users] dbtopow(), dbtorms(), powtodb(), powtorms() off by 100 db (Robert Poor)
by Perry R Cook 03 May '09

03 May '09

dB just implies 20log_10. A reference must be selected. The most common are dBV (1 volt = 0dB), dBm (0dB = 1 milliwatt into 600 ohms), and dBSPL (watts relative to threshold of hearing at 0dB). I suspect that the implementers of this were thinking about the approximate 96dB of 16 bit audio, and the +/-1.0 float recommended max range of STK. Thus a range of 0.00001=0dB to 1.0=100dB resulted. Easy to change to any reference by just subtracting/adding/multiplying/dividing by a constant. PRC

1 0

dbtopow(), dbtorms(), powtodb(), powtorms() off by 100 db
by Robert Poor 03 May '09

03 May '09

In chuck 1.2.1.2, the family of db conversion functions appear to be broken, or at least have a unconventional interpretation of db -- they all seem have an offset of 100 db: for example: Std.powtodb(1.0) => 100.0 (expected 0.0) Std.powtodb(10.0) => 110.0 (expected 10.0) Std.dbtopow(0) => 0 (expected 1.0) Std.dbtopow(100) => 1.0 (expected 10000000000) (Similar comments apply to rmstodb() and dbtorms()) OTOH they are self-consistent, in that Std.dbtopow(Std.powtodb(x)) == x, so maybe someone thinks that's how they're supposed to behave? - Rob

2 1

Useful code snippet: writing to mono or stereo files
by Robert Poor 03 May '09

03 May '09

Thanks to a tip from Tom Lieber (who pointed out that WvOut doesn't actually handle stereo files), here's a snippet of ChucK code people might find useful: if (me.args() > 1) { dac.chan(0) => Gain g0 => WvOut w0 => blackhole; dac.chan(1) => Gain g1 => WvOut w1 => blackhole; 0.5 => g0.gain; 0.5 => g1.gain; me.arg(0) => w0.wavFilename; me.arg(1) => w1.wavFilename; <<< "writing stereo output to files", me.arg(0), me.arg(1) >>>; } else if (me.args() > 0) { dac => Gain g => WvOut w => blackhole; 0.5 => g.gain; me.arg(0) => w.wavFilename; <<< "writing mono output to file", me.arg(0) >>>; } Since it attaches to the dac, you can put it just about anywhere in your ChucK program. When you invoke chuck as in : % chuck mytest.ck:bleeep.wav it will write everything your program sends to the dac to a mono "bleeep.wav" file. If you invoke it as in: % chuck mytest.ck:bleep_0.wav:bleep_1.wav it will write everything you program sends to the dac to two mono files: bleep_0.wav (left channel) andn bleep_1.wav (right channel). It's up to you to weave the two files together into a stereo sound file. There are several ways to do it -- I tend to use Audacity. - Rob

2 1

Re: [chuck-users] chuck-users Digest, Vol 45, Issue 43
by Scot Gresham-Lancaster 30 Apr '09

30 Apr '09

On Apr 29, 2009, at 5:12 PM, dan wrote: > M, we've had the players simply use their ears (!) to sync. this has > worked quite well, That is extra great. It is probably a pretty obvious statement, but using your ears while playing music often ends with a better result ;-) This does bring up an interesting and valuable general point about using new technology for music making, one that was a cornerstone over the years when technical compromises needed to be made putting together HUB pieces. ><((((º>.¸¸.·´¯`·.¸ ><((((º>.·´¯`·...¸><((((º>.· ´¯`·...¸><((((º> Scot Gresham-Lancaster http://scot.greshamlancaster.com "If I keep listening to Beethoven's Appassionata, I won't be able to finish the revolution. " - Vladimir I. Lenin ☭

2 1

Array documentation, such as .cap(), .size, etc.
by Andrew C. Smith 29 Apr '09

29 Apr '09

Where is the documentation for this stuff? I spent a ton of time just guessing and looking at other examples until I found out how to make an OSC event add a note to the end of an arpeggiating chord (very Glass-like). I got it working, although I might ask for help later on something related, but is there any comprehensive array documentation? I found .cap() used in the examples, but never explained. Thanks, Andrew

3 4

just play it...
by Robert Poor 28 Apr '09

28 Apr '09

Don't ask any questions. Not yet. Just play it. Then I'll explain (though some of you will guess what it is before you hear it)... - Rob

5 7

declaration oddity...
by Robert Poor 27 Apr '09

27 Apr '09

Dunno if this is a bug or a feature. Seems odd, though. Can someone explain what's going on? // Note that the following is perfectly legit float hx, hy; fun void h(float x, float y) { x => hx; y => hy; } // And this works without trouble float f_x[]; float f_y[]; fun void f(float x[], float y[]) { x @=> f_x; y @=> f_y; } // But when you elide the array declarations, you get an error: // NOT on the declaration line, but on the assignment of g_y: // [decl_test.ck]:line(17): cannot assign '@=>' on types 'float[]' @=> 'float[]'... // [decl_test.ck]:line(17): ...(reason: --- incompatible types for assignment) float g_x[], g_y[]; fun void g(float x[], float y[]) { x @=> g_x; y @=> g_y; // this is line (17) }

2 1

writing stereo files
by Robert Poor 27 Apr '09

27 Apr '09

How do I convince WvOut to write a stereo file? I tried (essentially): Pan2 pan => dac => WvOut writer => blackhole; writer.wavFilename("foo.wav"); and it wrote a mono file. I then tried: Pan2 pan => WvOut writer => dac; writer.wavFilename("foo.wav"); and it still wrote a mono file. I didn't see anything in the .pdf documents that suggested WvOut has a parameter to control the number of channels. Suggestions? - Rob

2 3

polyphony (what happens after note off)? was: Killing thread from without
by Kassen 27 Apr '09

27 Apr '09

Sorry, this was meant to go to the list, not just to Hans. ---------- Forwarded message ---------- From: Kassen <signal.automatique(a)gmail.com> Date: 2009/4/26 Subject: Re: [chuck-users] polyphony (what happens after note off)? was: Killing thread from without To: Hans Aberg <haberg(a)math.su.se> Hans; > Since there are no such limits in Chuck, I want in principle enable the same > generator to do note-on effects emulating real instruments. Well, I'd argue that modern computers do have the same limitation that hardware synths have; a finite amount of CPU resources. To complicate matters further; there are big differences between how various acoustical instruments deal with "voices"; a guitar is rather different from a harpsichord there even when the way of creating the sound is quite similar. > > You mean apart from scheduling decay cutoffs and the like. Yes, well, those are implicit in UGen behaviour and not so much "scheduled" as such, I feel. > It seems that problem that folks try to program around is that Chuck returns > references of class objects, without having a root tracing mechanism that > could be used for a GC. Sorry, that's beyond my expertise. I don't think we lack devices that "could be used for GC" as GC is being implemented right now. The issue, as I understand it, is that combining GC with realtime performance is tricky. Beyond that one of the DEV's will have to help you. > Chuck probably just gets its threads from the OS rather implementing in > effect an OS on top of the one already there, so that determines what it > should be capable of. Sorry, that's not quite right. ChucK runs in a single thread from the OS perspective and several "shreds" may run on the ChucK VM. The purpose of shreds is mainly to determine execution order in a deterministic yet convenient manner. We can't depend on the OS for that as not all OS's that ChucK runs on are capable of realtime performance (why MS and Apple don't implement this at least a s a option is beyond me but they don't). In short; there is a very real difference between "shreds" running in the ChucK VM and "threads" running on the OS (and supported by cores, etc); we don't just use those funny words because they are cute, even when some of us may enjoy such exercises in creative linguistics. In short that means that ChucK shred timing should be completely deterministic and extremely precise and when it's not that's a bug, it also means that for chucking multi-core cpu's won't do you much good. While it may sound like a complicated extra layer to implement "a new OS" on top of systems like Linux, OSX or Windows it does mean that we can share code across OS's with little regard for who runs what; I think that's quite nice. For a more in depth treatment on the how and why of ChucK's internal structure I'd like to refer you to this; http://www.cs.princeton.edu/~gewang/thesis.pdf Hope that helps, Kas.

2 3

polyphony (what happens after note off)? was: Killing thread from without
by Robert Poor 26 Apr '09

26 Apr '09

Hans, Eduard, community at large, I think what Hans is asking is "If you want a note to continue after a note-off event, what's a good way to program this in ChucK?" Attached is how I do it. The philosophy is simple: *Every* note-on event spawns a thread. That thread patches in the UGs and plays sound until there's a note-off event, at which it *begins* to shut down the note. Only after the note actually ends does the the thread unpatch the UGs and kill itself. That's the *philosophy*, but the implementation shown here deviates in an important way: A thread (and related UGs) are created on demand, but it is never killed: it blocks rather than terminates. And the object associated with the thread is never discarded: it is put into a resource pool and reused for the next note. If you hit C4 twice in a row, it will actually spawn two threads -- this is exactly what you want for something with a long decay. Don't let the length of the code scare you - most of it is comments. - Rob // File: ShredPoolExample2.ck // ================================================================ // // This program is free software: you can redistribute it and/or modify it under // the terms of the GNU General Public License as published by the Free Software // Foundation, either version 3 of the License, or (at your option) any later // version. // // This program is distributed in the hope that it will be useful, but WITHOUT // ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS // FOR A PARTICULAR PURPOSE. See the GNU General Public License for more // details. // // You should have received a copy of the GNU General Public License along with // this program. If not, see <http://www.gnu.org/licenses/>. // // ================================================================ // About ShredPoolExample2: // // ShredPoolExample2.ck is a example for the ChucK audio programming // and processing environment. It requires a MIDI keyboard or // equivalent source of midi note on/note off events. It demonstrates // three separate idioms: // // * How to implement a general purpose "resource pool". The basic // idea is that if you need an object, and there's one in the pool, // then you remove it from the pool and use it. If there isn't one // in the pool, only then do you allocate one from memory. When you // are done with the object, you return it to the pool. This way, // you will initially allocate some objects from memory, but // (hopefully) most of the time you'll be reusing ones you already // allocated. This techique is useful in ChucK since it lacks a // full garbage collection system. // // * How to create a Shred (thread) that can be started and stopped // for reuse. This is useful because ChucK does not garbage collect // shreads after they terminate, and memory will silt up. // // * One way to implement polyphony (including dynamic patching) and how // to handle "overhang" after a midi note ends. // // ================================================================ // USAGE: // chuck ShredPoolExample2.ck // // ================================================================ // Revision History // 1.00 22-April-2009: Robert Poor <rdpoor(a)gmail.com> // Original release. // // ================================================================ // ================================================================ // Class: Element // // Element defines any object that may be stored in a ResourcePool. // Any class that wants to be used in a resource pool must inherit // from Element. // class Element { ResourcePool @ _resource_pool; fun ResourcePool get_resource_pool() { return _resource_pool; } fun void set_resource_pool(ResourcePool @ resource_pool) { resource_pool @=> _resource_pool; } } // ================================================================ // ================================================================ // Class: ResourcePool // // ResourcePool maintains a "pool" of available elements. When you call // allocate_element(), it will pull an element from the pool if any are // available. If none are available, it calls create_element() to // create one and returns it. When you are finished with the element, // you MUST call release_element() to return it to the pool. // // Since you want create_element() to return your custom sub-class of // Element, you must also create a sub-class of ResourcePool with a // create_element() method to return one. (This is simpler than it // sounds -- see the MistralPool sub-class later in this file.) // class ResourcePool { Element @ _pool[0]; // the pool of available elements // Remove and return an element from the pool, if available. // otherwise call create_element() to create one from scratch // and return it. fun Element allocate_element() { null @=> Element @ element; if ((_pool.size() => int size) > 0) { _pool[size-1] @=> element; size-1 => _pool.size; } else { create_element() @=> element; <<< "Creating new element", element, "for pool", this >>>; element.set_resource_pool(this); } return element; } // Release an element to the pool fun void release_element(Element element) { _pool << element; } // This implementation of create_element() is a placeholder -- you // must create a subclass of ResourcePool whose create_element() // wil return an instance of your subclass of Element. fun Element create_element() { return new Element; } } // ================================================================ // ================================================================ // Class: ReusableShred // // In ChucK, one a shred (thread) exits, there's no way to restart it // or to reclaim its memory. Consequently, available memory will // eventually fill up after you've created many shreds. // // ReusableShred avoids this by creating shreds that never exit. A // ReusableShred has start() and stop() methods to make it start and // stop. Most of the functionality, though, happens in three methods // that you implement in a subclass: // // process_will_start() // called (in the processing thread) after the start() function // has been called, and just before the main processing loop starts. // process() // called (in the processing thread) once through each loop. // Looping continues until some agency calls the stop() function. // process_did_stop() // called (in the processing thread) after the stop() function // has been called, and just after the main processingn loop ends. // // Implementation note: The Shred is spork'd when it is created, and // it sits waiting for a trigger event (provided by the start() // function). After the stop() function is called, the thread reverts // to waiting for the next call to start(). // class ReusableShred extends Element { Event _trigger; int _runnable; // _initialize() is called once when the ReusableShred is created. fun void _initialize() { spork ~ _shred_process(); // NB: This call to yield() is cruicial and subtle: we need to // give the _shred_process() time enough to start and to block // on the call to _trigger => now. Without the call to yeild, // it is possible (and likely) that the user will call start() // before the _shred_process() blocks, meaning it will miss // the _trigger.broadcast() in start(), and so start() will // fail (until you call it a second time). [This was the // source of a bug until I figured out what was going wrong.] me.yield(); } _initialize(); // Start the processing thread. fun void start() { true => _runnable; _trigger.broadcast(); } // Stop the processing thread. fun void stop() { false => _runnable; } // Here is the entire processing thread. Notice that most of the // work will happen in the subclassed definitions of // process_will_start(), process() and process_did_stop(). // fun void _shred_process() { while (true) { _trigger => now; // block here until start() is called process_will_start(); while (_runnable) { process(); } process_did_stop(); } } // The following three functions may be subclassed (and at the very // least, you are expected to subclass the process() function). All // three of these functions are called from the same thread as the // _shred_process() loop. // process_will_start() gets called just before the shred's process // loop starts. fun void process_will_start() { } // process() is called each time in the processing loop. fun void process() { 1::second => now; } // process_did_stop() is called just after the processing loop has // ended. fun void process_did_stop() { } } // ================================================================ // ================================================================ // ================================================================ // Example code starts below // ================================================================ // ================================================================ // Class: Mistral // // Mistral is an subclass of a ReusableShred. It shadows much of the // functionality in the original class, though. // // Calling note_on() causes the shred process to call process_will_start() // and then to start waiting for call to note_off(). When note_off() is // called, the shred process calls process_did_stop() which *initiates* // the process of stopping the note -- but it doesn't actually stop it // yet. Only after the note ends does the shred process unpatch the UGs // and return the Mistral object to the pool of available objects for // re-use. NRev _ug_rev => dac; .1 => _ug_rev.mix; class Mistral extends ReusableShred { Event _release; Noise _ug_noise; ResonZ _ug_resonz; ADSR _ug_adsr; 1.0::second => dur RELEASE_TIME; _ug_adsr.attackTime(0.025::second); _ug_adsr.decayTime(0.05::second); _ug_adsr.sustainLevel(0.3); _ug_adsr.releaseTime(RELEASE_TIME); // Set up most of the patch, but don't connect it to the DAC yet. // We will complete the patch in process_will_start() _ug_noise => _ug_resonz => _ug_adsr; fun void note_on(int midi_key, int midi_velocity) { _ug_resonz.freq(Std.mtof(midi_key)); _ug_noise.gain(midi_velocity/127.0); _ug_resonz.Q(50.0); _trigger.broadcast(); // start the shred process running } fun void note_off() { _release.broadcast(); // "start stopping" the shred process } // We've shadowed the superclass definition of _shred_process with // our own primarily because there's no processing to be done // between a note on event and a note off event. // fun void _shred_process() { while (true) { _trigger => now; // block here until note_on() is called process_will_start(); _release => now; // block here until note_off() is called process_did_stop(); } } // This gets called before we enter the shred processing loop. fun void process_will_start() { _ug_adsr => _ug_rev; _ug_adsr.keyOn(); } // This gets called just after stop() is called (but still // in the processing shred(). Do whatever teardown needed. fun void process_did_stop() { // initiate the ramp down in the ADSR _ug_adsr.keyOff(); // hang until the ADSR completes RELEASE_TIME => now; // dynamically unpatch the UGs _ug_adsr =< _ug_rev; // Since processing has finished, this is the best place to // release this Mistral back to the resource pool. (Note that // get_resource_pool() is defined in the Element superclass.) get_resource_pool().release_element(this); } } // ================================================================ // ================================================================ // Class: MistralPool // // The MistralPool subclass of ResourcePool exists soley to define the // create_element() method, which just returns a new instance of a // Mistral. // class MistralPool extends ResourcePool { fun Element create_element() { return new Mistral; } } // ================================================================ // ================================================================ // ================================================================ // Top-level code starts here MidiIn midi_in; 0 => int midi_device; MidiMsg msg; MistralPool resource_pool; Mistral @ _active_notes[128]; // keep handles on active notes // ================ // open the MIDI port if (me.args() > 0) { Std.atoi(me.arg(0)) => midi_device; } if (!midi_in.open(midi_device)) { <<< "Can't open midi device #", midi_device >>>; me.exit(); } else { <<< "Opened midi device #", midi_device, "(", midi_in.name(), ")" >>>; } // ================ // "forever" loop starts here while (true) { midi_in => now; // block here until a midi event arrives while (midi_in.recv(msg)) { // ignore everything but key press messages if (isKeyPress(msg)) { // extract key number and velocity from the midi message msg.data2 => int midi_key; msg.data3 => int midi_velocity; // Theoretically, we can't get two note on events without // seeing an intermediate note off event. But sometimes // midi events are dropped (notably note off events). If // two note on events happen in a row for the same key, we // need to turn off the previous note, so we conditionally // do it here: note_off(midi_key); if (midi_velocity > 0) { // Here with a note-on event. We allocate a Mistral // from the pool, start it playing, and save a handle // to it in the _active_notes[] array so we can find // it when it's time to call note_off() note_on(midi_key, midi_velocity); } else { // Here with a note-off event. But we've already // called note_off() above. So nothing to do here. } } } } fun int isKeyPress(MidiMsg msg) { return (msg.data1 == 144); } // Allocate a Mistral from the pool, send it a note_on message and // stash a pointer to it in the _active_notes[] list so we know how // to send it a note_off message when the midi event arrives. fun void note_on(int midi_key, int midi_velocity) { resource_pool.allocate_element() $ Mistral @=> Mistral @ mistral; mistral.note_on(midi_key, midi_velocity); mistral @=> _active_notes[midi_key]; } // If there is an active note on this key, ask it do to a note_off() // and remove it from the list of active notes. The mistral will take // care of stopping its own processing and returning itself to the // resource pool when the note actually completes. // fun void note_off(int midi_key) { if (_active_notes[midi_key] != null) { _active_notes[midi_key].note_off(); null @=> _active_notes[midi_key]; } } // EOF

3 9

driving filter frequency from an envelope?
by Robert Poor 23 Apr '09

23 Apr '09

What's the chuck'ian idiom for driving a filter frequency from an envelope? Assume I have a primary signal chain that looks like this: Blit b => ResonZ z => Envelope e1 => dac; And I want to drive the center frequency of the ResonZ with another envelope. I know I could do it something like: Phasor constant => Envelope e2 => blackhole; constant.phase(1.0); ... and pepper my code with short delays that update the resonator's frequency: ... .01::second => now; z.freq(e2*440.0 + 100); ... but that seems both inelegant and computationally wasteful. I've looked at the .op inputs -- that may be the answer, but I can't quite tell from the documentation. So: is there a way to directly control the resonant frequency at the UG level without breaking back into "user code"? Thanks. - Rob

3 3

Killing thread from without
by Hans Aberg 23 Apr '09

23 Apr '09

Is it possible to kill a thread by saving a reference and calling exit() (or something) on that reference? Are there any means by which a created thread can be manipulated from without it by its reference? On a keyboard, I want a generator to be disconnected first some time after a key has been released - otherwise the sound will be truncated. How long depends on the generator, so I want to be able to set it arbitrarily. Then the problem is when the key is depressed again before this waiting time for disconnect has elapsed. One way to fix it is to let the thread check if the key has been depressed again, say by looking at the key down times, and if so, just skip the disconnect. But in order to avoid threads hanging around, it would be more logically to kill off the old one when the key is depressed again, as it is not needed anymore. So then write this function: BeeThree s[13][5]; // Sound generator for key coordinates x, y. ... fun void schedule_note_disconnect(int x, int y, dur t) { t => now; s[x][y] =< r; } When a key with coordinates x, y is released, schedule a disconnect: Shred @ note_disconnect[13][5]; ... 1 => s[x][y].noteOff; spork ~ schedule_note_disconnect(x, y, 1100::ms) @=> note_disconnect[x][y]; Then, when a key is depressed, I want to cheer it up using: if (note_disconnect[x][y] != null) note_disconnect[x][y].exit(); // Connect, set frequency and note on. However, it is easy to see that this exit(), though syntactically legal, does not affect the thread at all. So in the example above, a long note following one (on the same key) shorter than 1100::ms will be cut off. Hans

3 5

Inner loop array index bug
by Hans Aberg 23 Apr '09

23 Apr '09

I encountered what looks like a bug. In the sample code below, the array indexing in the line with the assignment of x0 causes the following error: [bug597534.ck]:line(22): array subscripts (1) exceeds defined dimension (0) It does not happen when the same kind of construct is used in the top loop, also as in the example code. Hans Aberg ---- Hid kb; HidMsg msg; if(!kb.openKeyboard(0)) me.exit(); <<< "Keyboard '", kb.name(), "' ready." >>>; // Key x-axis coordinate int x[256]; while(true) { kb => now; x[msg.which] => int y; x[msg.which] => int y0; while(kb.recv(msg)) { x[msg.which] => int x; x[msg.which] => int x0; } } ----

3 10