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

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

Colossal Error
by mike clemow 20 Apr '09

20 Apr '09

Yes! I finally made ChucK barf this up: mcchuck(23354,0x1825a00) malloc: *** Deallocation of a pointer not malloced: 0x603e7c; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug [chuck](VM): internal sanity check failed in shredule() [chuck](VM): (shred shreduled while shreduled) mcchuck(23354,0x1825a00) malloc: *** Deallocation of a pointer not malloced: 0x603e7c; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug [chuck](VM): internal sanity check failed in shredule() [chuck](VM): (shred shreduled while shreduled) mcchuck(23354,0x1825a00) malloc: *** Deallocation of a pointer not malloced: 0x603e7c; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug [chuck](VM): internal sanity check failed in shredule() [chuck](VM): (shred shreduled while shreduled) Killed I had to kill the process in the end, which was spinning in an infinite loop of some sort. I have to admit, the code I'm running ALWAYS crashes, however, often just with the regular Mac OS X 10.4 catch-all, "bus error". Full disclosure, this is a custom build of chuck with one minor modification: the Object.typeOf() stub is filled out with code from the Object.toString() method slightly modified to just return the string version of the class of the object so that I can determine the type of objects in code. But I never use that in the code I'm running right now. The bus error is totally repeatable in regular ChucK 1.2.1.2, but it's going to be a while before I get as spectacular a display as this. ;-) Of course, then I turn up the output of the VM to --verbose10, it won't crash properly, however, it does skip occasionally and tell me: [chuck]:(9:FINEST): (via rtaudio): OS-X audio output overrun detected! Perhaps increasing the buffer size on the audio system would help? I'll see if I can't get a trace of it crashing again. Cheers, Mike -- http://michaelclemow.com http://semiotech.org

1 0

UAnae / Vocoder question
by Peter Esveld 20 Apr '09

20 Apr '09

Hi ChucK List, While googling, I came across this really great shred that works as a vocoder: http://www.lullcec.org/chuck/fft/vocoder.ck<http://www.lullcec.org/chuck/fft/> The shred allows you to use a wav file as a "template" to vocode mic input. My question is this - can it be used with other shreds without vocoding all sound coming out of the Virtual Machine? Currently, any other shreds I add to the Virtual Machine have the wav file (vocoding) applied to them as well. I'm pretty new to ChucK, so please excuse the ignorance about these kinds of scoping issues. I've also attached the file in question (pretty much unmodified from the original). I'd like to use the vocoding effect only on sounds coming in from adc.left... I've emailed the author, and he's unsure what the problem is - he's going to investigate, but I'd really like some additional takes on the problem. Any thoughts or responses would be hugely appreciated! best, Peter -- Peter Esveld .......................................... 952.818.6488 peter.esveld(a)gmail.com ..........................................

3 5

Fixed so quickly.
by Andrew C. Smith 20 Apr '09

20 Apr '09

I didn't expect it to fix it that quickly, so sorry for the double-post. Here's what I did. This is my new eternal loop: while( true ) { // wait on midi event min => now; // get the midimsg while( min.recv( msg ) ) { // catch only noteon //if( msg.data1 != 144 ) // continue; // check velocity if( msg.data1 == 144 ) // THIS IS WHAT I CHANGED, from msg.data3 > 0 to data1 == 144. { // store midi note number msg.data2 => on.note; // store velocity msg.data3 => on.velocity; // signal the event on.signal(); // yield without advancing time to allow shred to run me.yield(); } else if( msg.data1 == 128 ) // ALSO THIS, from else to what it is now. This is to handle noteoffs which are all coming as [128 key 64] messages. I think I understand events now. { if( us[msg.data2] != null ) us[msg.data2].signal(); } } } Curious to know, has anyone else had problems with the polyphony examples? Although my keyboard seems to act in the expected way with Max/MSP (using midinote and poly~) ChucK will not see that. What's the deal exactly? -Andrew

1 0

Re: [chuck-users] The ChucK Show!
by Les Hall 18 Apr '09

18 Apr '09

Yeheheheah! The show rocked this week just like last week and Jan even got a recording! Next week: my Paranoid Schizophrenia album in it's entirety for the full show, and after that I'll once again shamelessly rip songs off of the ChucK wiki and etc etc etc... Please send your submissions to this email list, I'll play 'em! Take care, Les (Inventor)

2 1