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

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

String as an argument...
by Dimitri 08 Oct '08

08 Oct '08

Hey guys, first time posting here; short-time reader :) I've run into a bit of trouble programming a function to fade a ugen in or out. The code below will work nicely on g.gain however I can't abstract it to affect anything else without controlling the reference object, in this case *'g.' * The input is time 'x' in number of seconds. //==============================================// function void fadeOut(int x) { 1 => float master; x * 1000 => int top; for( 0 => int i ; i < top; i++ ) { if (master > 0) master - (master / (top * .2 )) => master => *g *.gain; 1::ms => now; } } //==============================================// Obviously the below would be my desired function, but even delving through ChucK's string class, it doesn't seem that there's a function to return an object reference from a string... //==============================================// function void fadeIn(int x, *string y*) { .01 => float master; x * 1000 => int top; for( 0 => int i ; i < top; i++ ) { if (master < 1) master + (master / (top * .2)) => master => *y*.gain; 1::ms => now; } } //==============================================// Am I crazy for thinking something like this would be useful? If anyone could offer some insight, even to a possible workaround, I'm all ears! Cheers, Dimitri. -- Duc, sequere, aut de via decede.

2 1

what a nice guy...
by Brad Garton 08 Oct '08

08 Oct '08

I saw this on the SC mailing list: http://gilesbowkett.blogspot.com/2008/09/fuck-chuck.html Too bad none of us are Real Musicians. brad http://music.columbia.edu/~brad

7 11

SoundFonts in ChucK
by Tom Lieber 06 Oct '08

06 Oct '08

I've confirmed that Kyle Super's code for using SoundFonts in ChucK is working with version 1.2.1.2 in OS X, and it is said to work in Linux as well. These are the steps I took to install: 1) Download and install FluidSynth from <http://fluidsynth.resonance.org/trac/wiki/Download>. I installed version 1.0.8 from source with "./configure && make && sudo make install" 2) Apply the attached diff to chuck 1.2.1.2. 3) Compile ChucK with "make osx". If on Linux, build with "make alsa". -- Tom Lieber http://AllTom.com/

3 8

(no subject)
by inventor-66＠comcast.net 04 Oct '08

04 Oct '08

Kassen, I will look into tools for EChucK, though I suspect it will be a mix of assembler and C tools due to the chaotic and buggy nature of Microchip tools. It doesn't look like there is popular enough support for EChucK to justify having its own sub-forum. Lots of reads but few posts, so I doubt if it needs its own sub-forum just yet. I emailed Ge as you suggest about the name and copied to you. Thanks, Les Dear Les, Some suggestions; *If you are going the PIC route you may need to start thinking about a SDK. Some of my best friends think ASM is fun but then again... I tend to hang out with relatively unusual people. *This is veering a bit off-topic; not all ChucKists will be interested in this and not everyone who is interested in this will be interested in ChucK. I suggest you ask Mosc for your own sub-forum on EM for this project. You are already linking to EM on your page about this and Mosc is very supportive of open DIY projects. If you don't have it I could give you his address. * I'd sugest you ask Ge about using the ChucK name for something related yet different like this. I could imagine using something like "SticK", a name that would refer to a possible result of "ChucKing" some object, it could refer to sticking objects to eachother and it might refer to educational uses as well. Something like that could save confusion. These are purely my own personal opinions at this moment but right now I feel this idea is evolving into something that does -and can- stand on it's own. I suspect a aproach like that could improve things for everyone; this is note some veiled way of saying "stay on topic"; I'll be keeping a close eye on this regardless of how and where it evolves. Yours, Kas.

1 0