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

faust2ck: Use FAUST to generate ChucK UGens
by Stephen Sinclair 02 Nov '08

02 Nov '08

Hi all, In an attempt to one-up myself on the tutorial and make it even easier to make new UGens, I've written a little script to help interface between FAUST and the ChucK code base. Check it out: http://www.music.mcgill.ca/~sinclair/content/blog/faust2ck_a_faust_wrapper-… (I tried putting it on the ChucK wiki but it didn't seem to want me to upload files, so it's hosted on my personal site for now.) Steve

3 3

UGen tutorial
by Stephen Sinclair 31 Oct '08

31 Oct '08

Hi folks, I started writing a little tutorial on how to create a UGen from scratch. This is for people who are comfortable with a little C/C++, of course. Anyways, feel free to help me make this as clear and easy as possible. For now it might be enough to get you going, at least, but it could probably be clarified a lot more. http://wiki.cs.princeton.edu/index.php/ChucK/Dev/UGen_Tutorial Steve

4 4

EChucK Delay
by Les Hall 31 Oct '08

31 Oct '08

Hi Folks, EChucK is on delay until January/February time frame. I got back the circuit boards but they were not routed out, so I will have to cut them with a diamond disk in my Dremel tool, which is OK, but I have no current budget for parts, programmer, or PC OS software that I need to do the PIC programming end of it. So things are on hold now due to lack of planning on my part. Basically I bit off more than I could chew, so to speak. So I will be putting the various pieces into place during the next few months and then getting back into it more furiously at a later time. Just an update for you, such as it is. Les (Inventor)

1 0

mouse position
by eduard aylon 23 Oct '08

23 Oct '08

Hello list, is there a way to track y-position of the mouse pointer. It's not in the manual. I know I can track the x-position with HidMsg.fdata thanks, eduard

5 7

bug on virtuality
by eduard aylon 18 Oct '08

18 Oct '08

Dear list, today I came across some (I believe) inconsistency related to virtual parent classes. The following code exemplifies such bug. There are three types of classes: Point -> in principle purely virtual Point2D and Point3D -> inherit from Point Point2D and Point3D need to be of the same parental type, so valid functions for both of them can be written in a single definition. See coordinates(Point p) and coordinates(Point p[]). The chuck interpreter complains when passing an array of Point2D or Point3D to the second function, claiming there is a type mismatch. In my opinion this should not happen. What do you think? eudard public class Point { // virtual class fun void set(int x, int y){} fun void print(){} } class Point2D extends Point { int _x; int _y; fun void set(int x, int y) { x => _x; y => _y; } fun void print() { <<< _x, _y >>>; } } class Point3D extends Point { int _x; int _y; int _z; fun void set(int x, int y, int z) { x => _x; y => _y; z => _z; } fun void print() { <<< _x, _y, _z >>>; } } fun void coordinates(Point p) { p.print(); } fun void coordinates(Point p[]) { for (int i; i < p.size(); i++) p[i].print(); } Point2D p2d; Point3D p3d; Point2D p2d_array[2]; Point3D p3d_array[2]; // this works: coordinates(p2d); coordinates(p3d); // this doesn't work // reason might be due to passing arrays coordinates(p2d_array); coordinates(p3d_array);

2 1

shred references (bug?)
by mike clemow 12 Oct '08

12 Oct '08

Dear list, I've decided to give "bus error" a proper kenning: "Clemow's Bane." Observe: //------------------------------------------------------------- // GrainDef version of tableMusic SinOsc s; fun void trig( float f ) { f => s.freq; } //------------------------------------------------------------- // osc event creator function fun OscEvent createOscEvent( string address, int port ) { OscRecv recv; port => recv.port; recv.listen(); recv.event( address ) @=> OscEvent oe; return oe; } // shred reference Shred ltrig; // chfreq shred definition fun void listenTrig() { createOscEvent( "/test, f", 12345 ) @=> OscEvent oe; while( oe => now ) { if( oe.nextMsg() ) { oe.getFloat() => float f; spork ~ trig( f ); } me.yield(); } } // this is the interesting bit... //------------------------------------------------------------- spork ~ listenTrig() @=> ltrig; // I KILL CHUCK V1.2.1.2 // spork ~ listenTrig(); // I DO NOT KILL CHUCK V1.2.1.2 me.yield(); while( true ) { 1::second => now; } //------------------------------------------------------------- This is generally how I do OSC servers in Chuck. I have to remove the shred reference in the latest version, however, or else my code crashes chuck hard. I haven't been able to test this out on a Linux box yet, but my guess is that someone should be able to make it barf something more helpful than "bus error." Kas, do you think that this is related to the bus errors we were getting assigning objects in that GrainPattern class? Cheers, Mike -- http://semiotech.org http://semiotech.org/michael

3 10

Re: [chuck-users] preprocessing chuck (was: Time to SMIRK!)
by Stephen Sinclair 12 Oct '08

12 Oct '08

On Sat, Oct 4, 2008 at 3:47 AM, Scott Wheeler <wheeler(a)kde.org> wrote: > Michael Heuer wrote: >> >> Might you be able to comment on this further? Many of us are >> clamoring for an include/import mechanism. Even if what you have done >> is messy, it sets precedence for how others might do the same. >> > > I wrote a ChucK preprocessor a while back: > > http://developer.kde.org/~wheeler/files/upchuck > > It checks the current directory and all dirs in the environment variable > CHUCK_DIRS for .ck files, and then you include stuff with: > > #include (Sequencer) > > It creates a temporary ChucK file to execute and also adjusts error messages > so that they correspond to the correct source file. That's great, but 'upchuck' now means something else for chuck. ;-) Anyways, you know you easily can use the C preprocessor on chuck files no problem: a.ck: <<<"This is a">>>; #define TEST "Test" #include "b.ck" b.ck: <<<TEST>>>; command line: $ gcc -x c -E -o test.ck a.ck $ sed 's,^# ,//,' --in-place test.ck $ chuck test.ck (The 'sed' line is needed because the C preprocessor produces some comment lines starting with #) Take note, though, that using #include is not the same thing as telling ChucK to pre-load another file! With #include the code is parsed and loaded into the VM as many times as it appears, so it's not the same thing as sharing public classes within the VM. In particular if you #include a file with a public class ChucK will refuse to load it twice. You'll also run into trouble if you try to #include two different files declaring public classes, since you can only have one public class per file. Steve

3 3

now v.s. actual time
by Kassen 10 Oct '08

10 Oct '08

Dear list, In this forum topic http://electro-music.com/forum/viewtopic.php?t=29358there is some talk about the time that a operation takes as compared to how it affects "now". As I said there; we may want to calculate a lot of numbers before starting synthesis (say in the case of a algorithmic score) and only start synthesis after we have those numbers. Right now you can't. You can tell ChucK to calculate those numbers, advance time by some amount estimated to be about as long as our CPU takes to do that and only start synthesis (by connecting to the dac) after that, but this will depend on a good estimate, which will of course differ with the CPU we may be on. Aside from this question there is the matter of how long a operation takes in a "strongly timed" language. In the past I have -unsuccessfully- tried to benchmark different versions of a operation using "now". We have a lot of ways of dealing with time, there are probably few languages that deal with time in as much detail as ChucK does but we have no way at all of dealing with time as registered by the clock next to the programmer. There is a paradox here; I'd like to be able to advance time by exactly as much time as was taken (by the cpu) since the last advancing of time; the problem with that is that determining this might itself take quite a few CPU cycles while this is the sort of operation we would use when trying to do things as quickly as possible. Another question is that we can't yield to the UGen graph if need be. A loop of just repeated yielding will stop the Ugen calculations. I have no solutions to this but thought this forum topic at least gave (yielded?) a new look at the question. For what it's worth, Kas.

4 16

Re: [chuck-users] EChucK!
by inventor-66＠comcast.net 09 Oct '08

09 Oct '08

Kevin, I really like your "stake header" connector idea. I had in my memory the thought that I had seen something like that before, but did not find it in the DigiKey catalog yet. By the way, here we just call them "headers". Those headers have got to be fairly inexpensive, and their mating connectors should be also. Your idea could also preserve the notion of using 22 ga solid wire to hold the "sculptures" in place. Some of the boards are quite small, with just a potentiometer or just a pair of DC blocking caps, and the larger ones are perhaps two inches by one inch. That's for the thru-hole version, but eventually I'd like to go with surface-mount for a really small footprint. Have a look at the front page of the EChucK website to see my most recent layout: http://www.freedomodds.com/music/echuck/ The board house wanted $159 to make and mill all those little circuit boards, times four. This would mean that my cost (or anyone else's, it's open-source) would be $40 per boardset, so I'd have to sell them for $60 or more and I don't think that's worth it. But with your headers I can fit much more on each panel. Great idea, thanks! Les (Inventor)

1 0

Re: [chuck-users] EChucK!
by inventor-66＠comcast.net 09 Oct '08

09 Oct '08

Hello again folks, I ran into some troubles with the board design for EChucK, specifically the connectors. Although the screw-down terminals I selected are fairly inexpensive, they are physically large and occupy too much of the board space. Also their cost dominates the cost of the boards, at about 40 cents US per node. Furthermore, as a friend points out, the method of interconnection is not foolproof, and in fact it is easy to make reverse power connections, which would of course destroy the chips. What I need is a super-inexpensive, small two-conductor connector that is hopefully semi-rigid and adjustable in length. Maybe what I'm looking for is a small Molex type connector or a header or something, I'm not sure, but it must be foolproof, small, and inexpensive. In the mean time I have recalled that DigiKey sells a miniature breadboard for $7.37 US, which would be perfect for prototyping EChucK. So I'm going to buy several of those and some parts for prototyping EChucK modules while I try to figure out the best connector system. Actually I wonder if the best connector is no connector at all. Users can simply solder the modules together. That would be a super low-cost approach and would lend itself to miniaturization very well. As a potential EChucK user, would you be opposed to soldering the components together? What connector system would you use? Les (Inventor)

2 1