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

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

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

Re: [chuck-users] Killing thread from without
by Hans Aberg 22 Apr '09

22 Apr '09

On 22 Apr 2009, at 17:31, Kassen wrote: >> It would be nice if one could generate a console display like when >> one is >> using programs like 'top -uR' or 'less'. That will work on >> computers that >> have terminal emulators like 'xterm' (and Terminal on Mac OS X). >> >> With it, one could display information about the output. For a >> playing >> keyboard, one might display information about the tuning, key >> shift, etc. > > I agree, that would be nice but I don't need it especially badly. Les Hall, thread "Keyboard Stuff", seemed trying to do something similar. > I > think there is probably more interest in extending the graphical > elements of the MiniAudicle. That would require more work. I'm not sure how the console display is done - perhaps it suffices with access to control characters. >> For high level GUI, Scala now uses Gtk2 (Gtk+). It is available on >> Linux and >> Windows, I think. On Mac OS X, the situation is a bit messy. There >> is a >> package that has bindings directly to Aqua: >> http://www.gtk-osx.org/ >> but works only in Intel. Otherwise, it is simplest to use MacPorts, >> but one >> gets absolute paths to /opt/, which is not good for a standalone >> distribution. Installing it alone requires a lot of package chasing. > > Yes, but ChucK itself (unlike the miniAudicle and the Audicle) doesn't > need any graphics manager. You can run ChucK from your CLI without > starting your graphical manager (I'm not sure OSX will allow that, on > Linux you can hit Ctrl + Alt + Fn where n is 1-6, in Windows you can > pick this at startup). I sometimes do that, if ChucK would use Gtk > we'd lose that ability. I have only run 'chuck' from the console. If there is a GUI, one does not need to start it - just have a command line option. >> Well, it may be intended, but "verbose" is not explained in the >> manual (just >> one occurrence). > > It's documented in the online docs; > http://chuck.cs.princeton.edu/doc/program/vm.html I tend to prefer a local PDF, as it is easy to search. > If you'd argue that that implies that "verbose0" should stop printouts > of started shreds I'd probably have to agree with you. I don't think > anyone anticipated that somebody would want to stop this kind of > printout but they could become a serious issue when we'd use shreds > for grains and would start sporking a few hundred per second. Yes, threads can be produced in large numbers: that is the point of them. Is there a way to schedule a thread ahead? Like in this pseudocode: // CReate a function for later use as thread: foo(int x, int y) {...} ... // set a thread foo(3,5) to start at time 1100::ms + now: schedule(foo(3,5), 1100::ms + now).id() => int id0; ... // If is pressed key: prevent the thread from sporking: if (id != 0) remove(id0); Hans

1 0