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

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

19 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

Diatonic keyboard
by Hans Aberg 18 Apr '09

18 Apr '09

I was able to find one working combination by simply disconnecting the generators when the keys are released. ChucK does not seem to consume much resources at all. So I report it back here (I will do more work later). It is nice to play both melody lines and chords. The attached file contains descriptions. Hans

1 0

Re: [chuck-users] Keyboard Stuff
by Hans Aberg 18 Apr '09

18 Apr '09

On 18 Apr 2009, at 08:26, Kassen wrote: > I agree with you here but I feel that voice cycling is quite > different from GC. Of course they can be similar; a voice that's no > longer used might become garbage, depending on the structure used It was not intended as a far reaching analogy - only that one may end up programming side issues rather than the main task. >> If there was a simple way, if that now was needed, to just being >> able to add generators and the program could sort out which ones >> were needed for the sound output, would that not be great? > > Yes, and it does this; ChucK only calculates UGens that are > connected (directly or through other UGens) to the dac or to > blackhole. No other UGens take cpu (at least not for calculating > sound). The problem with not calculating ones that are silent (as I > think you are sugesting) is that I might do things like have a > sample player connected through a envelope to fade it in and out > while it plays. If we wouldn't calculate the sample player we'd have > no way of knowing where in the sample it should be playing when it > is faded back in again. Yes, it may be a difficulty issue and not always possible. In the case of the fader, it must able report back to the source that it is not needed. - So there might be needed something similar to lazy evaluation or ray back-tracing. Such things must then be supported by the programming language. > ... what you likely need is a series of parallel sound sources and a > way to link those to notes. I will probably just start off with a few generators which will be allocated if available. There is a problem with key roll over on a typing keyboard, but one can learn to avoid it. >> Each new key, which initiates a sound generator, adds in CPU power >> after being allowed to settle down and not producing sound anymore >> about as much as 3 times when as full program at startup time. So >> there is a quick buildup of from these idle generators. > Yes. One of the factors here, aside from the BeeThree's is that you > use two Echo's and a reverb for each voice. Because both of those > effects are linear and time-invariant it doesn't matter (for the > sound) whether we send a BeeThree through it's effects, then mix the > effects together or whether we mix the BeeThree's and send all of > them through the effect chain. Now; while this may not matter to the > sound the second option does save us rather a lot of UGens, and > especially reverbs take a lot of CPU. I might try to simplify that. The echo effects may not be necessary at this point, I just want some pitches. > > Such a resource consuming problem might be fixed if each sound > generator could turn itself to sleep. Say there is a cutoff-level, > or something. > > Yes. there are two ways of doing that. First of all you can > "unchuck" (or disconnect) a UGen and when you do it will no longer > consume CPU. Like this; > > SinOsc s; > > while(1) > { > if ( s.isConnectedTo(dac) ) s =< dac; > else s => dac; > second => now; > } Thanks. I was just about to look for this. > Another way of making a UGen stop consuming cpu is to make the shred > that contained it's defininition (which is also the namespace > containing it) leave the VM. like this; > > JCRev r => dac; > .5 => r.mix; > > repeat(20) > { > spork ~ play ( Std.rand2(1,5) * 200, Std.rand2f(.5,2)::second ); > .5::second => now; > } > 5::second => now; > > fun void play( float freq, dur length) > { > SinOsc s => Envelope e => r; > .5 => s.gain; > freq => s.freq; > .5::length => e.duration; > 1 => e.keyOn; > .5::length => now; > > 1 => e.keyOff; > .5::length => now; > } > > Note, that while both methods free the CPU again neither frees the > memory used by the UGen. THat is less of a problem, in view of virtual memory. > I think that in the case of the last example we can free the memory > as well by making the function read like; > > > fun void play( float freq, dur length) > { > SinOsc s => Envelope e => r; > .2 => s.gain; > freq => s.freq; > .5::length => e.duration; > 1 => e.keyOn; > .5::length => now; > > 1 => e.keyOff; > .5::length => now; > > null @=> s; > null @=> e; > } > > that's a bit hacky though. It's good to get an idea of it. I did look a bit at the dynamic allocation of arrays. > Hope that clarifies. Yes. Thank you. Hans

1 0

Keyboard Stuff
by Les Hall 17 Apr '09

17 Apr '09

Hans, Yes, you can do it simpler than that. I don't know for sure but I think the degeneration problem is because you are ChucKing up patches dynamically but never unChucKing them. So they build on top of one another and corrupt. Not sure but that's my guess. This may not be quite your answer, but i did implement a monome-like keyboard interface in my Digitar program. It does a crude attempt at Karplus-Strong string synthesis, which amazingly sounds like a real guitar. When you start the program it is silent, then when you press alphanumeric keys that puts logic table entries into the boolean sequencer that plays the guitar. Press F1 thru F4 to page the monome-like keyboard interface among the four vertical positions in the logic table, and press other function keys followed by the +/- keys to adjust stuff like distortion, reverb, etc. Oh, and watch the console monitor for the user interface. Enjoy! Les

5 16

Re: [chuck-users] Keyboard Stuff
by Hans Aberg 17 Apr '09

17 Apr '09

On 17 Apr 2009, at 20:19, Kassen wrote: >> Even the ASCII keys may differ from the US, like the German >> keyboard layout, which swaps "z" and "y". > > There was a debate about that on this list a while ago. I think the > conclusion was "It's a confusing mess but it can be worked with with > some effort and care". Maybe that's just what I concluded though :¬). It strikes me that Chuck may not be good for mixing key numbers with the translated "AsCII" numbers. Ir seems one has to make choice of what to use. When mixing, one may want to pick up the event first and looking at both the key and the (eventual) Unicode number. So when doing a Hid kb; ... kb.recv(msg) one would want a function msg.char() that returns an "int": say -1 if no character, or the Unicode code point (character number) otherwise. Hans

1 0

Polyphony
by Hans Aberg 17 Apr '09

17 Apr '09

Is there a better way to have parallel sound generators? - The key map in the attached file quickly corrupts on my computer: I want one for each key. (It is set in E31 with the key "J" set at A = 440 Hz, in the layout C# D# E# C D E F# G# A# B# Cb Db Eb F G A B Fb Gb Ab Bb C' And the organ sound generator is from hid/keyboard-organ.ck.) Hans

1 0

Re: [chuck-users] Using typing keyboard for playing
by Hans Aberg 16 Apr '09

16 Apr '09

On 16 Apr 2009, at 02:33, Kassen wrote: >> There are problems with using MIDI-patches as they may not be able >> to produce intermediate pitches - pitch bends en E12 may also >> change tone color. > > Yes, I see. Fortunately with ChucK you can implement pitch-bend (if > you'd like to use it) in any way you see fit. There is a MIDI Tuning Standard (MTS) which allows one to set frequencies, but it is not widely implemented. And even that ignores the problem of scale stretch. >> Actually, I only played piano accordion. I was led to the diagram >> when trying to find something better than the E12 buttons. > > Me too, and now, years after I quit, I still have a inclination to > want to put musical keyboards vertical on the rare occasions that I > play them :¬). There is the Korg nanoKey which resembles accordion piano keys somewhat, and the Roland virtual accordions, but they are a bit ore pricey. Otherwise, the key map was known (in a mirror reversed version) in the 19th century, by Helmholtz and Bosanquet. >>> I myself favour the exact opposite in keyboards; a longer key- >>> travel with a distinct "click" (like the IBM Model "M"). Odd, >>> maybe as I used to play the accordion and still have one stored. >> >> There are different styles, but the sensitive firm touch is good >> for full-grown accordions when playing rapid music (like Balkan >> music). >> >> When playing buttons, the hand must be m,ore curved, and one cannot >> use much force. So I think more sensitive keys would be better for >> that. > > Oh, yes, I wouldn't dream of using the style of keyboard I like for > typing on a accordion. Composers use MIDI keyboards for typing when entering the score (into programs like Finale and Sibelius). >>> For your purposes the best tip I could probably give is that the >>> "midi" section of the examples also touches on polyphony. I think >>> you will benefit from looking at those examples as you are clearly >>> after chords. >> >> Perhaps, if one can avoid that microtonal tone color problem. > > Without pitch-bend I'd still assume you would want your keyboard to > be polyphonic. I don't think those examples even go into pitch-bend > but I might be mistaken. I meant that those examples will show you > how to do voice-cycling which is a rather useful technique as it > will avoid "garbage" in ChucK. Yes, thank you, it will take me some time to get to those examples. On keyboards, I think even when playing a single line legato, there will be overlap of keys. Once (two decades ago) I had a MIDI synth with limited simultaneous notes, and with too few sound generators assigned, the audio would be truncated. Hans

1 0

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

16 Apr '09

Adam, Thanks for the bio info, I'll read it or some of it next show. If you are looking for drums, then perhaps you will like kijjaz's drum class which is at the end of the attached file. It's my Generator program which creates No Wave, Rock, and Relaxation music. The switch at the top of the file selects which type, and it is set for Rock to demo the drums best. Please feel free to use, modify, distribute, or even profit from it. Les

1 0

Using typing keyboard for playing
by Hans Aberg 15 Apr '09

15 Apr '09

I want to be able to play from the typing keyboard - the idea is that a note of specific frequency should be sounded as long as the key is held down. (Typically in an generalized diatonic key layout.) The function KBHit.getchar() does not seem to be the right thing, because it just gives a value when the key is depressed, not when it is released, and further, does not disable "key repeat". In addition, it would be better to get the key numbers, not the text key map translated values which may change (and not work one special key combinations). So can this playing functionality be achieved somehow? Hans Aberg

3 6

performing with laptops
by Jay Klein 15 Apr '09

15 Apr '09

Hi all, I'm getting ready to start playing shows with a band that will mix live instrumentation with material from a laptop (primarily using Live, and ChucK at some point I hope). I've never done this before and I'm not sure of the best way to connect a laptop to a typical rock club's mixer/PA. I've found a small number of answers on the web that range from a simple cable between the laptop's headphone jack and RCA inputs on the mixer, to a firewire audio interface and a stereo DI box. Audio quality and hum from AC power are mentioned as reasons to go with more advanced solutions. I don't want to spend money and carry around these devices unnecessarily, but I'd also hate to be unprepared or inflict bad sound on the audience. There must be a lot of experience with this on this list, so what do you think? Apologies for the arguably off-topic post, but I wasn't sure where else to turn. I'll try to redeem myself with something more directly ChucK-related in the future. Thanks, -Jay

4 3

The ChucK Show
by Les Hall 14 Apr '09

14 Apr '09

Adam, Thanks for your "conductor" dance music generator. After the holiday socializing I finally kranked it up and tested it with a simple microphone patch on a new setup. It sounds great! I'm going to feature it on this week's ChucK show. The new setup is miniAudicle on eMac with Y cable to headphones and split to a patch cable that connects emac headphones out to netbook line-in where edcast broadcasts. I can do it all on the eMac using soundflower but I don't have enough CPU for ChucK *and* MuSE broadcaster, so hence the use of two computers. Oh, by the way to make ChucK use relative paths you just put a dot in front of the filename, like this: "./dir/filename" instead of "/dir/filename", and in miniAudicle you go to preferences to select the current directory. I modified you code to work this way by addind the dots in the right files. Do you have any biographical information for me to read or paraphrase as I introduce your program? Anything would be good... Thanks, Les (Inventor)

2 1

push but no pop?
by Robert Poor 14 Apr '09

14 Apr '09

This note contains a coding tip, a feature request and a bug report. In that order. CODING TIP: Resource pools are a simple way to avoid memory allocation. This should be old hat to veteran coders, but I remember thinking this was a cool technique when I first saw it. This is important in embedded systems (that lack malloc()/free()) and also in ChucK (which doesn't GC heap-allocated objects). The concept is simple: you keep an array (a "pool") of available items. When you want an item, you take one out of the pool, or create one if the pool was empty. When you're done with the item, you just chuck it back in the pool for the next time someone wants it. The code is simple. Let's say you created some structure, like a NoteEvent, that you'll be using heavily in your ChucK code. By "heavily", I mean you'll be creating thousands of these every second: public class NoteEvent { float frequency; float commercial_potential; int makes_adults_complain; } How do you keep ChucK's memory from getting silted up? Use a resource pool. Here's the code. NoteEvent @ _noteEventPool[0]; fun NoteEvent allocateNoteEvent() { null @=> NoteEvent @ noteEvent; if ((_pool.size() => int size) > 0) { // pop a NoteEvent from the end of the _pool, if available _pool[size-1] @=> noteEvent; size-1 => _pool.size; } else { // the pool is empty, create a new one new NoteEvent @=> noteEvent; } return noteEvent; } fun void freeNoteEvent(NoteEvent @ noteEvent) { // push noteEvent onto the pool so it's available for the next // call to allocateNoteEvent(). _pool << noteEvent; } Call allocateNoteEvent() when you need a noteEvent, call freeNoteEvent() when you're done with it. You're responsible for freeing them when you're done with them -- it's not automatic -- but if you free each event that you allocate, ChucK will not allocate any memory above what' needed. FEATURE REQUEST As written, array's popBack() function has a void return. It would be nice if popBack() returned the element it removed, so we could write the code like this: fun NoteEvent allocateNoteEvent() { null @=> NoteEvent @ noteEvent; if (_pool.size() > 0) { _pool.popBack() @=> noteEvent; } else { new NoteEvent @=> noteEvent; } return noteEvent; } BUG REPORT This may be operator error rather than a bug, but the following code: fun Element allocateElement() { if ((_pool.size() => int size) > 0) { _pool[size-1] @=> Element @ element; size-1 => _pool.size; return element; } return new Element; } reports: chuck(20184,0xa018a830) malloc: *** error for object 0x5eb6e0: double free *** set a breakpoint in malloc_error_break to debug I think the problem may be in "return new Element" -- it may be trying to return the Element itself, rather than a reference to the Element. If that's the case, though, it seems like something that should be caught at compile time. - Rob

3 2

SndBuf.read() BUG & feature request
by Kassen 13 Apr '09

13 Apr '09

Fellow ChucKists, I was trying to detect the successful loading of a wave file, hoping that SndBuf.read() wpuld return "true" upon successfully opening a file like when opening a HID device and "false" otherwise. Instead it turns out that the following code seg-faults. SndBuf foo; <<<"kick.wav" => foo.read>>>; Aside from how this means losing the whole VM, which is bad, such functionality would permit for the implementation of search-paths. For example; when a relative location doesn't work we might want to append the file-name to a string expressing the absolute location of some directory filled with samples. Yours, Kas.

1 0

Audicle on Ubuntu
by Beinan Li 11 Apr '09

11 Apr '09

Hi ChucKers, I tried the latest Audicle on my Ubuntu 8.04, building was a breeze, but I found problems: 1. Conflicts with Compiz-fusion: When the compiz-fusion visual effects are turned on, Audicle GUI's redraw looks really confusing: I can see other APPs bleeding through Audicle here and there. Also, moving the window only expands its size. Remove the system visual effects and it appears normal again. 2. Trying to kill the Audicle window with the system "Force window to quit" tool caused system crash. This happened with or without Compiz. Beinan

1 0

The ChucK Show
by Les Hall 11 Apr '09

11 Apr '09

Hey folks, The ChucK show was a big success this week. None of the technical problems of last week, and I was properly caffeinated prior to the show, lol, so I was nervous but did well. The microphone on the eMac is much better than the one on the Acer netbook (though I lub my wittle netbook), and playing recorded ChucK was WAY easier than doing live ChucK with Reaper and a cable between two computers, dang. Although Blue_Hell lost his recording and I didn't record, there will be plenty more shows to enjoy. We had 9 listeners at one point, and I even did a "featured ChucKist" of Kassen this week... Please send in your ChucK programs or recordings, we need them for the show. I will announce some historical info about each song if I can, so just fill me in. email ChucK Show content to me: inventor-66(a)comcast.net. Don't make me search out the web for ChucK music, lol, because you know I will if I have to! :) :D Thanks, Les (Inventor)

1 0