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

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 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