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

Re: [chuck-users] negative duration syntax and bug
by Les Hall 16 Nov '08

16 Nov '08

Hi Lucas, I am sorry if my little joke backfired and you misinterpreted it as being in poor taste. Kassen knows my sense of humor so he got it, and he joked right back at me. Any language with sporks and upChucKs can't be taken too seriously, lol! Cheers and don't do anything I wouldn't do (twice)! Les (Inventor) p.s. remember: "Time flies like an arrow, fruit flies like a banana."

3 2

LiSa SndBuf rate bug?
by mike clemow 15 Nov '08

15 Nov '08

Hey folks, In the below example (which you will all find in the LiSa-SndBuf.ck file in examples in your installation), after populating the buffer in the LiSa object with the values of the samples from SndBuf, the rate of the LiSa object is set equal to 2. in order to play back normally. Why is it not 1? Why this should be the case makes little sense to me and I respectfully submit this as a bug, unless someone can provide a reasonable explanation. Thoughts? -Mike ----- //ugens SndBuf buf; LiSa lisa => dac; //change this path to your own sample "/Users/dan/Files/Chuck/LiSa_examples/TomVega.wav" => buf.read; //set lisa buffer size to sample size buf.samples() * 1::samp => lisa.duration; //transfer values from SndBuf to LiSa for ( 0 => int i; i < buf.samples(); i++ ) { //args are sample value and sample index (dur must be integral in samples) lisa.valueAt(buf.valueAt(i), i::samp); } //party on... 1 => lisa.play; 2. => lisa.rate; //look at some of the data //returns value at given time, with linear interpolation <<< Std.rand2f( 0., lisa.duration() / 1::samp ) :: samp => lisa.valueAt >>>; //hang on until it's done... lisa.duration() * 0.5 => now; -- http://michaelclemow.com http://semiotech.org

4 15

Re: [chuck-users] negative duration syntax and bug
by Les Hall 15 Nov '08

15 Nov '08

Press Release: In a startling discovery made earlier today by musician and self-described ChucKist "Kassen", it was revealed that negative time actually exists. Long theorized by science fiction authors and audiences, the discovery has baffled modern scientists. When questioned, the mysterious "Kassen" was unavailable for comment because he had travelled back in time to enjoy last weekend's party one more time. It is, however, suggested by other ChucKists that the time reversal phenomenon exists only in the mind of ChucK and is in fact a bug. Presumably a bug that flies backward, but that, again, is pure speculation. In fact, the whole concept of negative time in a ChucKian universe may actually be a very carefully planned practical joke created by the ChucK Dev team in the future of the past which is actually now. This has been an up-to-the-minute report (so to speak). Les (Inventor)

3 3

negative duration syntax and bug
by Kassen 13 Nov '08

13 Nov '08

Fellow ChucKists, This is runs; <<<-1 * second>>>; Hence we know that negative durations are fine. This, on the other hand causes a problem; <<<-1::second>>>; We can get around that by using this; <<<(-1)::second>>>; That one does run but it also seems very clumsy to me. I'm getting the impression that for durations expressed like -3::second the minus sign somehow isn't a part of the number while elsewhere it is. This doesn't strike me as very coherent. While I was testing some other things around negative durations I noticed that this will crash with seg-fault; second -=> now; Admittedly it would be a type of expression that would only be useful with negative durations... Probably quite rare but it shouldn't crash the whole VM like that. Yours, Kas.

1 0

array declaration bug
by eduard aylon 12 Nov '08

12 Nov '08

Hello list, I found out that declaring arrays in this way: float a[], b[]; is buggy, as it seems the type for b[] is not taken as float. Maybe something else happens here (maybe passing by ref), I haven't check thoroughly (don't know if it happens with other types as well). See the following code: // ******************************* // this works: // ******************************* float freq, amp; fun void Do( float freq, float amp) { <<<"do sthg">>>; } Do(freq,amp); // ******************************* // also works: arrays declared in separate lines // ******************************* float freq1[1]; float amp1[1]; fun void Do( float freq[], float amp[]) { <<<"do sthg">>>; } Do(freq1,amp1); // ******************************* // throws error :argument type(s) do not match // arrays declared in the same line // ******************************* float freq2[1], amp2[1]; Do(freq2,amp2);

2 2

dangerous games with shreds
by eduard aylon 11 Nov '08

11 Nov '08

Sorry list for bombing you with so many questions, but got this funny one, which I thought would be interesting to post. The patch below loops endlessly although no while(true) loop exists in the "main". If you try the patch, be warn that your computer may (or may not) become unresponsive. The code makes sense, and the behaviour as well, but should chuck throw a warning when something like this happens? I came up with this, while trying to have a process for reading and another for writing, but didn't want to advance time in any of them. eduard class mySpork { Event write; Event read; fun void start(){ read.signal(); <<<"started">>>; } fun void Write() { // NOTE: time is not advanced in this function while(true) { write => now; //<<< "writing" >>>; read.signal(); } } fun void Read() { // NOTE: time is not advanced in this function while(true) { read => now; //<<< "reading" >>>; write.signal(); } } } mySpork myspork; spork~myspork.Read(); spork~myspork.Write(); me.yield(); myspork.start(); <<< "loops forever">>>; 1::second => now; <<< "and never gets here">>>;

4 5

64-bit chuck
by Roger Critchlow 10 Nov '08

10 Nov '08

Greetings Chuckists -- This looks like a lot of fun, but I have one axe to grind. I see that the question of 64-bit chuck came up on the mailing list 2 years ago and after reviewing the code I can see why nothing has happened since. It's a little unfriendly to be so coy about this. You're very careful to discourage Mac and Windows users from attempting to recompile from sources. But someone who's trying to compile on a 64-bit operating system gets no warnings, no cautions, no under construction signs, nothing from the download and build web pages to indicate any problems at all. If you look through the information files of the downloaded sources for indications of 64-bit problems, you find: VERSIONS: - corrected more issues on some 64-bit systems VERSIONS: - corrected issues on some 64-bit systems Until you get around to fixing it, could you at least mention somewhere on the web pages or in the information files that your code truncates 64 bit pointers to 32 bits before dereferencing them so we can stop figuring it out the hard way? Please? Thanks, -- rec --

1 0

yet another lisa bug?
by eduard aylon 09 Nov '08

09 Nov '08

Hi Dan and others, I don't think this is the expected behaviour for lisa: when duration is set, the number of maxVoices is reset to 10, the default. Please, check attached patch. eduard LiSa lisa; lisa.maxVoices(100); <<<lisa.maxVoices()>>>; lisa.duration( 1::second); <<<lisa.maxVoices()>>>;

2 2

division by zero bug
by eduard aylon 09 Nov '08

09 Nov '08

Hi, the following code does not crash nor throw any exceptions: 0 => float z; 2::second => dur n; n/z => dur k; // division by zero!! while(true) { k => now; } althought it does throw a floating point exception when types are ints, it doesn't when types are floats or time based. Well, at least on my system: OS X Leopard. eduard

1 0

MiniAudicle CVS (Mac OS X)
by Juan-Pablo Caceres 09 Nov '08

09 Nov '08

Hi everyone, Which is the latest stable CVS (or SVN) of miniAudicle/Chuck for OS X? I didn't have luck googling (sorry if this has been asked before). The latest release of miniAudicle is version 0.1.3.9 (with ChucK: version 1.2.1.2 (dracula)) Both are fairly old (more that a year as far as I can tell), so I'd love to get the latest version. Thanks! Juan-Pablo

2 3

LiSa .rate() issue (bug)
by Kassen 09 Nov '08

09 Nov '08

Dear list (especially Dan), I just spend a hour or so pulling my hair out wondering why my little toy turntable wouldn't "scratch" anymore. It turns out that the issue is some changed behaviour in LiSa's .rate(). I believe .rate() no longer automatically casts integers to floats while previously it did. The following example demonstrates the issue; //============8<================= LiSa l => dac; second => l.duration; //just making sure <<<l.rate(), " default rate">>>; //note this is a integer -1 => l.rate; <<<l.rate(), " should be -1 but isn't">>>; -1.0 => l.rate; <<<l.rate(), " should be -1">>>; //============8<================= I'm not sure how this can happen as casting integers to floats is supposed to be automatic in ChucK. If somebody could please look into this? Yours, Kas.

3 7

help understanding lisa
by eduard aylon 07 Nov '08

07 Nov '08

Hello list, I am trying to build a granular patch with lisa, but for some reason I am getting clicks every time lisa repeats the buffer. Maybe it has to do with lisa's duration? Hope someone can explain me what I am doing wrong. Following I attach two examples one uses lisa the other uses an array. The one that runs with lisa has clicks, the other sounds pristine, why? (even if rampup and rampdown were set for lisa). The strange thing is that if recorded to file and checked with an audio editor I can't see any strange artifacts in the waveform. thanks for any help, eduard // the patch that uses lisa: LiSa lisa => dac; 1024 => int size; size::samp => lisa.duration; for (int i; i < size; i++) { lisa.valueAt(Math.sin(2.0*pi*60*i/size), i::samp); } 1 => lisa.play; while(true) { lisa.rampUp(10::samp); lisa.duration() - 20::samp => now; lisa.rampDown(10::samp); } // the other patch with a simple buffer: Impulse imp => dac; 1024 => int size; float buffer[size]; size - 1 => int bitmask; for (int i; i < size; i++) { Math.sin(2.0*pi*60*i/size) => buffer[i]; } 0 => int pos; while(true) { buffer[pos&bitmask] => imp.next; pos++; 1::samp => now; }

6 18

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

03 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 24 Oct '08

24 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 19 Oct '08

19 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 13 Oct '08

13 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 10 Oct '08

10 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 10 Oct '08

10 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