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

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

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 28 Apr '09

28 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