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

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

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

22 Apr '09

On 22 Apr 2009, at 13:26, Kassen wrote: >> ChucK needs to pipe these to some other process. Scala gets around >> this >> somehow - it uses Gtk. > > Right, but plain ChucK -intentionally- doesn't depend on a graphical > server (like X on Linux, Explorer on Windows and Quartz/Aqua on OSX). 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. > Most people will of course be using graphics and a mouse but you *can* > use it without which might get relevant for installations and the like > (or even when you simply don't feel like graphics). I'm not sure there > is anything we could pipe it into that can be depended on cross > platform. 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. >>> It would help to increase your >>> buffer size but of course that would go at the expense of latency. >> >> I'm not sure what buffers there are - I am on Mac OS X, which is >> Unix. > > Buffers will be the same regardless of your platform. They refer to > how many samples ChucK sends to your soundcard at a time. If your > buffersize is larger there is more leeway for interuptions as the > "deadline" to be done calculating the samples isn't quite as frequent. I see now there is a --bufsize(N) option. Thanks. >> It is more how I expect compilers to work. Both optimizations and >> extra >> warnings should one turn on by hand. > > Yes, but there is a difference between the typical usage of -say- GCC > and ChucK; with GCC your write it once and when it work it will > compile all the time, hopefully for everyone and you are done. I'd say > ChucK sits between that and something like Prolog where it's normal to > have a dialogue with the interpreter until results are right. Frequent printouts may cause problem, unless the printout delay problem can be solved. The problem with the thread-kills is that the programmers might have thought it being a rare event, like an exception, and not used as frequently as on every key release. >> Anyway, it turns out that --verbose0 does not turn it off. So in >> view it >> chokes on printouts, it is a bug. > > I respectfully disagree. I think everything works as intended and > documented (here...). Well, it may be intended, but "verbose" is not explained in the manual (just one occurrence). > I do think that turning all printouts off would > be a good and useful feature to have, maybe something like > "--verbose-1". I could see many cases like yours where printing except > for printing from the code itself wouldn't have any use at all and it > can indeed cause delays. Sporking hundreds of shreds, for example when > using grains, could become a serious issue on some systems. One can write stuff to a file, and then look at it using 'tail -f'. File writes are usually fast, and will not (I think) be disturbed by looking at it from another process. Info about thread-kills might be rewritten to stderr, as opposed to stdout, and redirected to a file. Hans

1 0

Reusable Thread, Resource Pools, Polyphony: all in one....
by Robert Poor 22 Apr '09

22 Apr '09

After seeing several people struggle with "how do I do polyphony", I thought I'd pass along the ChucK code for how I do it. The example may seem like overkill, but it's clean and serviceable. It's really three examples in one: * How to do Resource Pools (useful in a ChucK world without a full Garbage Collector) * How to not leak threads, er, I mean shreds (ditto) * How do to polyphony (with dynamic patching and unpatching) I ran this example for a long time and verified that it doesn't continually grow. Here's the deal: it's a LONG code example (though most of it is comments). If someone else wants to put in in a safe, friendly place for the ChucK community, I will thank you for doing so. If you have questions about the code, I'm an easy mark and will do my best to answer (schedule permitting). And finally, if you know how to make the code better, by all means, create a revision. It should be obvious from the layout of the code that a "production" version would split this into three or four independent files, but it was easier to package everything in a single file for demoware. Oh, a polyphonic MIDI version will follow within the next day or two. Share and enjoy... - Rob // File: ShredPoolExample1.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 ShredPoolExample1: // // ShredPoolExample1.ck is a standalone example for the ChucK audio // programming and processing environment. 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). // // ================================================================ // USAGE: // chuck ShredPoolExample1.ck // // ================================================================ // Revision History // 1.00 21-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 PlinkerPool 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, once 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 yield, // 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: Plinker // // Plinker is a subclass of a ReusableShred. It defines the "big // three" functions of ReusableShred: process_will_start(), process(), // and process_did_stop(). // // In this case, process_will_start() sets up parameters to play some // repeated notes and patches a Mandolin into the signal chain. The // process() function plays a note (repeatedly), and calls stop() when // the repetition is to end. Finally, process_did_stop() unpatches // the Mandolin from the signal chain. // // I'd like to think that David Jaffe would enjoy the results. NRev _ug_rev => dac; .1 => _ug_rev.mix; class Plinker extends ReusableShred { // pick a note, any note. but note, these dice are loaded. [0, 0, 0, 2, 4, 6, 7, 7, 9, 11 ] @=> int _scale[]; Mandolin _mandolin; time _end_time; dur _plink_duration; float _freq; // This gets called before we enter the shred processing loop. fun void process_will_start() { now + Std.rand2f(3.0, 12.0)::second => _end_time; Std.rand2f(0.5, 0.05)::second => _plink_duration; Std.mtof(21 + Std.rand2(2, 5) * 12 + _scale[Std.rand2(0, _scale.size()-1)]) => _freq; // dynamically patch UG into output _mandolin => _ug_rev; } // This gets called once every time through the loop. Note // that it's perfectly safe to call stop() from within the // shred. fun void process() { if (now > _end_time) { // Stop the repeating note by calling stop(), // defined in the ReusableShred super-class stop(); } else { _freq => _mandolin.freq; Std.rand2f(0.2, 0.9) => _mandolin.pluckPos; 0.5 => _mandolin.pluck; _plink_duration => now; } } // This gets called just after stop() is called (but still // in the processing shred(). Do whatever teardown needed. fun void process_did_stop() { // dynamically unpatch the Mandolin _mandolin =< _ug_rev; // Since processing has finished, this is the best place to // release this Plinker back to the resource pool. (Note that // get_resource_pool() is defined in the Element superclass.) get_resource_pool().release_element(this); } } // ================================================================ // ================================================================ // Class: PlinkerPool // // The PlinkerPool subclass of ResourcePool exists soley to define the // create_element() method, which just returns a new instance of a // Plinker. // class PlinkerPool extends ResourcePool { fun Element create_element() { return new Plinker; } } // ================================================================ // ================================================================ // ================================================================ // Top-level code starts here PlinkerPool resource_pool; while (true) { // Note: We allocate a Plinker from the pool here. We release the // Plinker to the pool in the Plinker::process_did_stop() method // (see above). resource_pool.allocate_element() $ Plinker @=> Plinker @ plinker; // Start playing a note. All the performance parameters are set // in Plinker::process_will_start() (see above). plinker.start(); // Start a new Plinker every two seconds. 2::second => now; } // EOF

3 2

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

22 Apr '09

On 22 Apr 2009, at 00:01, Kassen wrote: >> I also checked (I think) that it wasn't due to CPU overloads. They >> seem to >> be due to delays in the program. > > Yes, that's right. Printing to the screen is a relatively slow > process, the same holds true for CSound and SC; it's a universal > problem even for modern computers. ChucK needs to pipe these to some other process. Scala gets around this somehow - it uses Gtk. > It would help to increase your > buffer size but of course that would go at the expense of latency. I'm not sure what buffers there are - I am on Mac OS X, which is Unix. >> Thank you. I was starting to think along those lines. But the >> default should >> be that all such printouts are turned off, and turned on in a debug >> mode. > > I can see where you are coming from but personally I think the > defaults do make sense, though maybe the info when sporking from > within code isn't as needed as the feedback at adding files or using > Machine.add(). I'm not sure the VM itself makes that distinction, > maybe sporked shreds are the same as other shreds there with the one > difference being namespace, that would make a lot of sense, > considering the provisions for future extension in the direction of > smaller granularity in updating running code for livecoding purposes. It is more how I expect compilers to work. Both optimizations and extra warnings should one turn on by hand. > Still; when you care about performance and want to configure ChucK to > your needs (that can of course differ from project to project) you are > likely starting ChucK with a set of flags and parameters already > (buffer size number of channels, etc, etc). A simple batch file or > BASH script would take care of it for you. Anyway, it turns out that --verbose0 does not turn it off. So in view it chokes on printouts, it is a bug. Hans

1 0

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

21 Apr '09

On 21 Apr 2009, at 23:05, Kassen wrote: >> One problem is that one gets a lot of printouts: >> [chuck](VM): removing shred: 32 (spork~exp)... >> When using <<< ... >>>, printouts cause a slight delays, that at >> least on a >> slow machine may make fast keyboard playing impossible. > > That's a good point. I can't look into this right now as I'm packing > for a livecode/jam session. I also checked (I think) that it wasn't due to CPU overloads. They seem to be due to delays in the program. So if you have a live performance with some rapid movements and delays are a problem, make sure to turn off as much printouts as possible. > I think you may be able to stop ChucK from > printing those by tweaking the "verbose" commandline flag but I'm not > sure about that. Thank you. I was starting to think along those lines. But the default should be that all such printouts are turned off, and turned on in a debug mode. Hans

1 0

MIDI event problems-- no note-off events
by Andrew C. Smith 20 Apr '09

20 Apr '09

I'm running into problems getting the MIDI polyphony working. Specifically, in the ChucK examples, I'm catching all of the noteon messages but none of the noteoffs. One thing, I don't really understand what "off @=> us[note];" is supposed to do, when "off" is an Event. Basically, all of my noteon messages are coming as [144 key vel] while my noteoffs are coming as [128 key 64]. How does this work? I don't see anything for message 128 in the source code. I'm testing on this one: http://chuck.cs.princeton.edu/doc/examples/midi/polyfony2.ck Thanks everyone. I tried reprogramming my keyboard (Korg Kontrol49) but I couldn't figure out how to make it work. Andrew

2 1

variables and memory
by Bozelos Dimitris 20 Apr '09

20 Apr '09

Hi all, as i've read in the documentation or maybe in some email in this list, ChucK lacks garbage collector. If my understanding is correct this means that it does not automatically free the memory that any variable needs after getting out of its scope. So this probably mean that if I run a loop that declares a variables like for( int i = 0; i < 100; i++; ) { int var1; float var2[10]; // do things } and have this code called many times inside an infinite loop and do other stuff in other shreds, after a while it's inevitable to run into problems. Is this correct? Is there anything like c++'s delete to free memory? Dimitris ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

5 12