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

eChucK Update
by Les Hall 23 Mar '10

23 Mar '10

Hi again ChucKists, The current news on eChucK is that the first run of Karplus Strong boards is now assembled and tested working. I sold nine boards, three assembled, and kept one. To date two are working and demonstrated in various formats at electro-music.com, the host of the ChucK forum. The latest move forward is that I finally looked into the details of performing physical modeling of instruments in analog circuit form. It turns out that I can use the same translation methodology to convert instrument models coded in ChucK into physical analog circuits. I was doing it all along with Karplus Strong, it's just that now i've learned more and realized I can make a flute module or a trombone module or whatever. Although this has been done using modular synthesizers before, I have not yet heard of any commercially available modular synthesizer modules that do this. So that's the update, I'd be happy to hear any advice or warnings or news on the topic. At this time I am not familiar with the legalities of using potentially copyrighted models or patented ones, etc. I have a lot to learn but it should be worth it because I think there's a pretty good market for this stuff. Plus it's tons of fun! Les (Inventor)

1 0

before we extend ChucK... [was: Guile C++ wrap]
by Robert Poor 22 Mar '10

22 Mar '10

These are all great ideas, but before we dazzle Ge and others with our brilliant extensions to ChucK, we might focus on getting one or two missing features implemented. :) :) To name just one: the lack of super() results in contorted code. *Much* further down on my list are things like closures, duck typing and introspection. I'm just sayin'... - Rob On Mon, Mar 22, 2010 at 07:53, Hans Aberg <haberg-1(a)telia.com> wrote: > > On 22 Mar 2010, at 15:07, Kassen wrote: > > One of the main things that I like about Scheme is the REPL. >> >> It struck me that the original plan for chuck --shell isn't completely >> unlike a REPL in how interaction might work for performance or rapid >> prototyping. We have some framework for that, in that our parser, compiler >> and VM all live in the same memory space so if we would want to update some >> function foo() the system should be able to find what bytecode was generated >> from the original foo() and replace that with the new one. >> >> Sadly that idea hasn't received much attention in recent days, but in the >> Bad Old Days it was treated as rather central to ChucK. >> >> Personally I'm more interested in the method of interaction than in the >> exact language used for it; I'd rather look into that stuff than into a more >> functional (in the CS sense of the word) syntax as such. >> > > The way Guile works, being a library, is that there are functions for > interpreting code. So I implemented those functions into some class objects, > so that one can write: > function1<integer, integer> inc("(lambda (x) (+ x 1))"); > instead of the > symbol<integer> x("x"); > function1<integer, integer> inc = x >>= x + 1; > > Now a read-evaluation-print loop just has a line editor which reads input > lines and passes it to some such function, and the prints back the resulting > string. - There is a function display() by which any object can be made > human readable, though not in a way that it can be converted back to Scheme > code. > > So perhaps ChucK might be made into some library, though it is great of not > having to fiddle around with C/C++ programming. But having the option might > be useful. > > > Hans > > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

2 1

Yamaha recall
by Hans Aberg 22 Mar '10

22 Mar '10

Though off-topic, it is pretty funny if you are interested in music. Hans http://groups.google.com/group/rec.music.theory/browse_frm/thread/62b7de0cf… http://tinyurl.com/ygqt45q

1 0

simple message logger for ChucK
by Robert Poor 21 Mar '10

21 Mar '10

I would guess this has already been written, but I got tired of writing and then commenting out trace / debugging comments in my ChucK code, so I put together this simple class modeled loosely after similar packages in Java other languages. It comprises all static functions, so you can call it from anywhere. If someone wants to extend the log() function to write to a file or stream, be my guest -- currently it simply prints to <<< >>> (stderr). Here is the code in its entirety. Share and enjoy. - Rob // File: log.ck // Log: A simple logging facility for ChucK // // Loosely modeled after logging packages in other languages, Log // allows you to sprinkle your code with print messages tagged with // different severity levels. What gets printed at run time depends // on the setting of the log severity level. The levels (from lowest // to highest severity) are: // // TRACE // DEBUG // INFO // WARN // ERROR // FATAL // // A simple example of usage: // ================ // class ArrayFns { // fun int iterate(Object things[]) { // Log.debug(this, "entering iterate()"); // if (things == null) { // Log.warn(this, "null array, returning 0"); // return 0; // } // for (0 => int i; i<things.size(); i++) { // if (Log.severity(Log.TRACE)) Log.log(this, "iterate(), processing " + i); // process(things[i]); // } // things.size() => int retval; // if (Log.severity(Log.DEBUG)) Log.log(this, "exiting iterate() with " + retval); // return retval; // } // } // ================ // The explanation: // // The line: // Log.debug(this, "entering iterate()"); // will print the message if Log.set_severity() is DEBUG or TRACE. // // The line: // Log.warn(this, "null array, returning 0"); // will print the message if Log.set_severity() is WARN or lower // (WARN, INFO, DEBUG or TRACE). // // The line: // if (Log.severity(TRACE)) Log.log(this, "iterate(), count=" + i); // is equivalent to: // Log.trace(this, "iterate(), count=" + i); // except that the latter form will always evaluate its arguments, // which in this case causes string catenation. You can avoid the // extra evaluation by using the first form, which will call Log.log() // iff the current severity level is TRACE. This is especially useful // in inner loops that are called often, or if the construction of the // error message itself is particularly costly. // // ==== Authors: // Robert Poor <r(a)alum.mit.edu> // ==== Revision History: // 20100321_214041: Initial Version // ==== public class Log { static int TRACE; static int DEBUG; static int INFO; static int WARN; static int ERROR; static int FATAL; static int _severity; fun static void init() { 0 => TRACE; 1 => DEBUG; 2 => INFO; 3 => WARN; 4 => ERROR; 5 => FATAL; set_severity(WARN); } // get/set the severity level fun static int get_severity() { return _severity; } fun static void set_severity(int severity) { severity => _severity; } // Return true if Log is at severity or lower fun static int severity(int level) { return level >= _severity; } fun static void trace(string msg) { log_if(TRACE, msg); } fun static void trace(Object o, string msg) { log_if(TRACE, o, msg); } fun static void debug(string msg) { log_if(DEBUG, msg); } fun static void debug(Object o, string msg) { log_if(DEBUG, o, msg); } fun static void info(string msg) { log_if(INFO, msg); } fun static void info(Object o, string msg) { log_if(INFO, o, msg); } fun static void warn(string msg) { log_if(WARN, msg); } fun static void warn(Object o, string msg) { log_if(WARN, o, msg); } fun static void error(string msg) { log_if(ERROR, msg); } fun static void error(Object o, string msg) { log_if(ERROR, o, msg); } fun static void fatal(string msg) { log_if(FATAL, msg); } fun static void fatal(Object o, string msg) { log_if(FATAL, o, msg); } // Conditionally log fun static void log_if(int level, string msg) { if (severity(level)) log(msg); } fun static void log_if(int level, Object o, string msg) { if (severity(level)) log(o, msg); } // Unconditionally log fun static void log(string msg) { log("[toplevel]", msg); } fun static void log(Object o, string msg) { <<< now, me, o.toString(), msg >>>; } } // setup static constants and defaults at load time. Log.init(); // ===== EOF =====

1 0

what is the syntax for casting an array of objects?
by Robert Poor 20 Mar '10

20 Mar '10

I'm getting a message: > [babble_patch.ck]:line(142): arguments type(s) do not match: [babble_patch.ck]:line(142): ... for function > 'PatchableObserver.attach_all(...)' ... [babble_patch.ck]:line(142): ...(please check the argument types) The line in question in file babble_patch.ck:line(142): > PatchableObserver.attach_all(_handlers); The declaration of _handlers in babble_patch.ck:line(76): > Handler @ _handlers[]; The declaration of the Handler class in babble_patch.ck:line(37): > class Handler extends PatchableObserver { ... } And the declaration of attach_all in patchable_observer.ck:line(16): > fun static void attach_all(PatchableObserver ps[]) { ... } What I *intend* is to pass an array of Handler objects to attach_all(). I can imagine that ChucK is concerned that Handler isn't the same as PatchableObject (don't laugh at me -- I've gotten used to Ruby's duck typing). But I can't figure out the syntax for casting an array of Handler[] as an array of PatchableObject[] to pass to attach_all(). Any ideas? [If need be I can make a smaller self-contained example. But my hope is that this is some easily answered question.] Thanks in advance, - Rob

1 1

Complete and utter Newbie
by James Mcwilliam 19 Mar '10

19 Mar '10

Hi I just came across ChucK after dabbling with SC, Common Music and Max/MSP. I basically know nothing about programming but ChucK looks very interesting and I'd like to know more. I've download the executable file (Mac OS 10.6.2) and I've dropped the folder "chuck-1.2.1.3-exe' into applications. I've followed the instructions and opened the terminal and now I'm stuck..... The instructions say go to bin/directory (replace chuck-x.x.x.x.-exe with the directory name). What and where is bin/directory? You'll have to forgive my complete stupidity, I'm an 'acoustic composer' trying to dabble with electronic based music and so far i cant even install ChucK. Messing around with my terminal seems scary, am I likely to blow my computer up?? Any help would be greatly appreciated. Many Thanks James

4 6

creating midi ports without connecting
by Atte André Jensen 13 Mar '10

13 Mar '10

Hi The following is from "polyfony.ck": // device to open (see: chuck --probe) 0 => int device; // get from command line if( me.args() ) me.arg(0) => Std.atoi => device; MidiIn min; MidiMsg msg; // try to open MIDI port (see chuck --probe for available devices) if( !min.open( device ) ) me.exit(); I see and use this all the time; creating midi out/in ports by connecting to something. But how can I create a midi port that's not connected to anything? -- Atte http://atte.dk http://modlys.dk

2 3

sending out midiClock
by Atte André Jensen 12 Mar '10

12 Mar '10

Hi I'm trying to manipulate a stream of midi clock messages with a chuck script, but fail. Below is a stripped down example that just sends the received messages out again: MidiIn min; MidiOut mout; MidiMsg msg; if (!min.open(0)) me.exit(); if (!mout.open(4)) me.exit(); while(true){ min => now; while( min.recv(msg)) { <<<msg.data1>>>; mout.send(msg); } } However, when I send it a stream of midi clock messages it prints the following: 248 :(int) [chuck](via RtMidi): RtMidiOut::sendMessage: event parsing error! 248 :(int) [chuck](via RtMidi): RtMidiOut::sendMessage: event parsing error! 248 :(int) [chuck](via RtMidi): RtMidiOut::sendMessage: event parsing error! 248 :(int) [chuck](via RtMidi): RtMidiOut::sendMessage: event parsing error! It doesn't seem to send anything out mout. Am I doing something wrong? -- Atte http://atte.dk http://modlys.dk

1 0

sndbuf glitch
by Scott Smallwood 09 Mar '10

09 Mar '10

Hey ChucKians, So, I've talked to some of you about this problem before, and have been given various solutions, including playing with chunking, but so far, nothing has been able to resolve this basic issue. It's really kept me from doing any significant work with sound buffers ChucK. Here's the issue: When you read a file into a sound buffer - doesn't matter how large the file is, the audio "clicks". Doesn't matter what else is currently "playing", whether it's an oscillator, another sndbuff, etc - it just invariably clicks. Case and point: ---- SndBuf s1 => dac; SndBuf s2 => dac; 0 => s2.gain; //turn down the gain of 2 so you can hear the click "file1.aif" => s1.read; 2::second => now; "file2.aif" => s2.read; 2::second => now; ---- So, this script starts playing the first file, then in 2 seconds when it loads "file2.aif" into the other SndBuf (who's gain is turned town) - CLICK! I know - this can be resolved by loading all needed soundbufs at the top of the code, but this is very restrictive. I want to be able to load in new audio on-the-fly - but currently, Chuck simply doesn't seem to support this basic feature. Anybody have any clues here? --ss [ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ] - [ - ] S c o t t S m a l l w o o d composer, sound artist faculty of arts, u of alberta scott.smallwood(a)ualberta.ca http://www.scott-smallwood.com http://www.ecnedive.com

3 6

Why doesn't this work?
by Matt B. 09 Mar '10

09 Mar '10

Hey guys I'm trying to do a simple chuckle, but something's going wrong when I try to set s.freq... SinOsc s=>dac;Phasor p=>blackhole;p.freq(2);while(1){Math.sqrt(1/p.last())*100=>s.freq;10::ms=>now;}; If I dump "Math.sqrt(1/p.last())*100" I get floating values as expected between 100 and 700, but when I chuck it to s.freq, no sound is output, and s.last() is always 0. Am I missing something or is this a bug?

2 3