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

On Division, Arithmetic and expressions
by Jim Hinds 10 May '06

10 May '06

Kassen has run into a "feature" of chuck that needs some explanation. The apparent strange behavior of division of integers is common among most computer languages that support integers. The basic common feature is that we want integer computations to result in integers. If it starts with all integer variables and constants, we want to finish with integers (when possible.) You learned about integer division well before you learned about fractions or decimals, and WAY before you learned binary. You remember that the answer to 2 / 3 was: "it doesn't go even once" -- that's zero. The result is well defined and consistent. Integer division goes hand-in-hand with the remainder operation (mod, % or whatever in other languages). In most cases, you don't notice the subtle nature of integer computations. 5 + 3 = 8 is much the same as 5.0 + 3.0 = 8.0 if the answer is float or int, you just don't care. It is, however, important when you do division. It is ALSO important when you are working with "big" numbers (or very negative numbers). When this happens, well formed integer arithmetic will overflow in a predictable way (and we want it that way). For example, since 32767 (2 raised to the 15th power minus 1) is the largest positive number in 16 bit twos-complement arithmetic, we DO WANT our integer computation to result this way: 32767 + 1 = -32768. And not as 32768.0. Yes, this is bizarre, and probably not what you are expecting. But it is very common for computer languages, and those of us with little music and much computer (that's guys like me), it is like breathing: we are so aware of it, that we don't even mention it. OK, so how do you GUARANTEE that there is no funny stuff happening (like truncation or overflow)? Simple. You FORCE at least one side of the operation to be in floating point. The operation is then carried out in floating point and the result is in floating point. Example: 2/3 == 0 (integer divides integer results in exact integer), BUT 2.0 / 3 == .66666667 (integer divides float results in non-exact float) or 2/3.0 == .666666667 (float divides integer results in non-exact float) or float(a) / 3 should result in a float, not an integer. This is mostly the way it is. (you can tell I'm a programmer, since I almost always put that caveat word "mostly" in my explanations: there always seems to be an exception. I hope this helps to understand integer computations in chuck, and other languages. > Kassen sez: > > Hi list, > > Deviding a int by a int results in a int returned like here; > ------ > <<<(2 / 3)>>>; > > //or even like this; > > 2 / 3 => float a; > <<<a>>>; > ------ > > Is that realy the intended behaviour? > In that last case I personally find what happens a bit silly. > > If this realy is the way it should be I think it would be nice to add > a line about this to the manual because I only found out what was > happening exactly after several rounds of testing. Perhaps this is > typical behaviour for some languages but I wasn't used to it. > > Yours, > Kas. > > Jim Hinds http://www.jahbini.org/

2 1

devide issue?
by Kassen 10 May '06

10 May '06

Hi list, Deviding a int by a int results in a int returned like here; ------ <<<(2 / 3)>>>; //or even like this; 2 / 3 => float a; <<<a>>>; ------ Is that realy the intended behaviour? In that last case I personally find what happens a bit silly. If this realy is the way it should be I think it would be nice to add a line about this to the manual because I only found out what was happening exactly after several rounds of testing. Perhaps this is typical behaviour for some languages but I wasn't used to it. Yours, Kas.

2 2

zipper noise
by plutek 05 May '06

05 May '06

greetings! first off..... i am thoroughly enjoying ChucK; thanks a lot! my question is whether anybody has an elegant way of attacking the problem of zipper noise when using external MIDI controllers which send only integer values. it's great that ChucK uses float MIDI values, but we need a way of smoothing incoming controller data -- perhaps something like pd's "line" operator. i'll have to give some thought to how it could be built from scratch, using native primitive operators, but an optimized higher-level function to take care of this would certainly be useful. thanks again! .pltk.

3 6

benchmarking chuck
by eduard aylon 02 May '06

02 May '06

Hello list, Not sure this issue is still of any interest, but just for the record I got up to 836 sine oscillators without crackles. At 836 I got 1 crackle and got the second crackle around 900 sines. Above 960 sine oscillators the crackles appear more often. This is on a Mac Intel Core Duo 1.83GHz, 1GB DDR2 SDRAM, OS 10.4.6 . It make no difference to have my settings under System Preferences > Energy saving as Normal or Best Performance. The code I have used is: 1024 => int max; sinosc @ a[max]; 0 => int counter; sinosc s1; 440 => s1.freq; 1./max => s1.gain; while( true ) { s1 @=> a[counter] => dac; .25::second => now; <<<"oscillator ", counter++>>>; } cheers, Eduard

4 9

Re: [chuck-users] KBHit and arrow keys
by Jim Hinds 30 Apr '06

30 Apr '06

The behavior of KBHit is kind of standard for ketting data from some asynchronous source. Since the chuck program (or any user prog) runs at some unknown speed it is possible for several keys to be pressed before you get control. In that case the boolean (KBHit) returns true. Your input routine would then process all the characters in the input buffer. That's why kb.getchar returns (and removes) the first char in the input buffer. When kb.getchar returns zero, you know that you have processed all of the input. This allows KBHit to get re-enabled so that it will indicate when new stuff is available. This isn't unique to the keyboard, but is pretty much the way all interrupt driven I/O works. So, be happy: what you thought were warts in your program were really elegant solutions to a universal problem. Or something like that. Jim Hinds jahbini(a)jahbini.org http://www.celarien.com/ http://www.jahbini.info/ On Apr 27, 2006, at 6:00 AM, chuck-users- request(a)lists.cs.princeton.edu wrote: > Send chuck-users mailing list submissions to > chuck-users(a)lists.cs.princeton.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > or, via email, send a message with subject or body 'help' to > chuck-users-request(a)lists.cs.princeton.edu > > You can reach the person managing the list at > chuck-users-owner(a)lists.cs.princeton.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of chuck-users digest..." > Today's Topics: > > 1. KBHit and arrow keys. (Kassen) > > From: Kassen <signal.automatique(a)gmail.com> > Date: April 26, 2006 10:22:12 AM HST > To: "ChucK Users Mailing List" <chuck-users(a)lists.cs.princeton.edu> > Subject: [chuck-users] KBHit and arrow keys. > Reply-To: ChucK Users Mailing List <chuck- > users(a)lists.cs.princeton.edu> > > > Hello all, > > The new keyboard input is great but getting the arrow and F1-F10 and > so on keys to work is kinda tricky, I found. I cooked up a sorta kinda > maybe solution to this that I thought might be useful to others as > well. See below. > > use the up and down keys to increase or decrease "bla", then print > bla's current value. This won't win any beauty contests but it does > work. I'm not at all sure why it needs two temporary variables but I > can't get it to work without them. If I don't use temporary variables > it seems that I can only use one test on kb.getchar() before it > disappears(??) and one test isn't enough for anything beyond the most > simple of triggers. The same method could be used to get function keys > to work. > > I hope this is of use to some. This works on my IBM- compatible laptop > running XP, no refunds if it turns out Mac's use some entirely > different way of reading the keyboard; I have no idea how those work. > If it's found useful I could add it to the Wiki? > > Yours, > Kas. > > > ---------------------------------------------------------------------- > -------- > // the keyboard input > KBHit kb; > > //some setting that's of great importance somewhere > int bla; > > > // time-loop > while( true ) > { > // wait on kbhit event > kb => now; > > // potentially more than 1 key at a time > while( kb.more() ) > { > //store number to avoid it getting lost after one check > kb.getchar() => int K; > > //arrow keys are encoded in two numbers with the first being 224 > if (K == 224 ) > > { > //wait for the second number > kb => now; > > //the same "anti number disapear" trick > kb.getchar() => int L; > > //do intuitively sensible stuff to "up"... > if(L == 72) 1 +=> bla; > > //........and "down"...... > if(L == 80) 1 -=> bla; > > //...and make the result go somewhere. > <<<"bla is", bla>>>; > } > else > { > //do something else to normal keys > <<<K>>>; > } > } > } > ------------------------------------------------- > > > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

3 4

multiple class declaration
by eun.sung＠no-log.org 29 Apr '06

29 Apr '06

Hi list. I declare in a same .ck file two different classes, a standard and a public one. I try to instance an object of the standard class in the public one. This seems to be "unauthorized". Is it a normal behaviour? Is there another way to do that? Greetings.

1 0

KBHit and arrow keys.
by Kassen 26 Apr '06

26 Apr '06

Hello all, The new keyboard input is great but getting the arrow and F1-F10 and so on keys to work is kinda tricky, I found. I cooked up a sorta kinda maybe solution to this that I thought might be useful to others as well. See below. use the up and down keys to increase or decrease "bla", then print bla's current value. This won't win any beauty contests but it does work. I'm not at all sure why it needs two temporary variables but I can't get it to work without them. If I don't use temporary variables it seems that I can only use one test on kb.getchar() before it disappears(??) and one test isn't enough for anything beyond the most simple of triggers. The same method could be used to get function keys to work. I hope this is of use to some. This works on my IBM- compatible laptop running XP, no refunds if it turns out Mac's use some entirely different way of reading the keyboard; I have no idea how those work. If it's found useful I could add it to the Wiki? Yours, Kas. ------------------------------------------------------------------------------ // the keyboard input KBHit kb; //some setting that's of great importance somewhere int bla; // time-loop while( true ) { // wait on kbhit event kb => now; // potentially more than 1 key at a time while( kb.more() ) { //store number to avoid it getting lost after one check kb.getchar() => int K; //arrow keys are encoded in two numbers with the first being 224 if (K == 224 ) { //wait for the second number kb => now; //the same "anti number disapear" trick kb.getchar() => int L; //do intuitively sensible stuff to "up"... if(L == 72) 1 +=> bla; //........and "down"...... if(L == 80) 1 -=> bla; //...and make the result go somewhere. <<<"bla is", bla>>>; } else { //do something else to normal keys <<<K>>>; } } } -------------------------------------------------

1 0

Building ChucK for Ubuntu 5.10
by Sean M Gomez 25 Apr '06

25 Apr '06

I'm sure this is a real n00b question, but are there any known problems building ChucK for Ubuntu Linux? I've hit a compile error with rtaudio that I'm not seeing a way around. Any help is appreciated. sean -- Sean M. Gomez ITS - Desktop Support Specialist Wesleyan University

3 4

My solution: HyperArray class
by David Powers 22 Apr '06

22 Apr '06

Hello, my solution to the array problem was to create a new class, "HyperArray", which has functions for insert, remove, remove duplicates. It holds an array, currently of size 1024, but the methods make it appear as if it's an array of variable length. So, I'm going to have the Cell class inherit from HyperArray, and simply add methods that are specific to manipulating arrays of notes (or whatever) in serial fashion. If anyone wants to test this class out more, I'd appreciate it. There may be some things wrong, because when I used the get() method internally, in the shuffle function, it crashed check for reasons I don't really understand. Here's the code: //HyperArray public class HyperArray { //initialize 1024 => int max; 0 => int hyperLen; float hyperA[max]; //set fun void set(float a[]) { a.cap() => hyperLen; for (0 => int i; i<hyperLen; i++) { a[i] => hyperA[i]; } } //get fun float[] get() { float temp[hyperLen]; for (0 => int i; i<hyperLen; i++) { hyperA[i] => temp[i] ; } return temp; } //print fun void print() { for (0 => int i; i<hyperLen; i++) { <<< hyperA[i] >>> ; } } //remove fun void remove (int index) { hyperLen--; for (0 => int i; i < hyperLen; i++) { if (i==index || i>index) { hyperA[i+1] => hyperA[i]; } } } //insert fun void insert (int index, float item) { hyperLen++; get() @=> float temp[]; for (0 => int i; i < hyperLen; i++) { if (i==index) { item => hyperA[i]; } if (i>index) { temp[i-1] => hyperA[i]; } } } //sort fun float[] sort() { float temp; for (0 => int x ; x < hyperLen-1; x++) { for (0 => int y; y < hyperLen-x-1; y++) { if (hyperA[y] > hyperA[y+1]) { hyperA[y] => temp; hyperA[y+1] => hyperA[y]; temp => hyperA[y+1]; } } } return hyperA; } //remove duplicates fun float[] removeDup() { int purge[hyperLen]; 0 => int purgeIndex; for (0 => int i; i<hyperLen-1; i++) { for (i+1 => int j; j<hyperLen;j++) { if (hyperA[i]==hyperA[j]) { j => purge[purgeIndex]; purgeIndex++; } } } for (purgeIndex => int k; k>0; k--) { remove(purge[k-1]); } return hyperA; } //reverse fun float[] reverse() { float newA[hyperLen]; hyperLen - 1 => int counter; for (0 => int i; i<hyperLen; i++) { hyperA[i] => newA[counter]; counter--; } set(newA); return(hyperA); } //shuffle fun float[] shuffle(int times) { float newA[hyperLen]; for (0 => int i; i<hyperLen; i++) { hyperA[i] => newA[i] ; } //--- Shuffle elements by randomly exchanging each with one other. for (0 => int i; i<times; i++) { for (0 => int j; j<hyperLen; j++) { std.rand2(0,hyperLen-1) => int r; // generate a random position newA[j] => float temp; newA[r] => newA[j]; temp => newA[r]; } } set(newA); return(hyperA); } } fun void testShiz() { HyperArray booyah; <<<"Set and print array">>>; booyah.set([5.0,2.0,3.0,4.0,5.0,1.0,2.0,3.0]); booyah.print(); <<<"Remove item at index 3 and print HyperArray">>>; booyah.remove(3); booyah.print(); <<<"insert value 4.0 at index 3 and print HyperArray">>>; booyah.insert(3,4.0); booyah.print(); <<<"Remove duplicates and print HyperArray">>>; booyah.removeDup(); booyah.print(); <<<"Sort and print HyperArray">>>; booyah.sort(); booyah.print(); <<<"Reverse and print HyperArray">>>; booyah.reverse(); booyah.print(); <<<"Shuffle and print HyperArray">>>; booyah.shuffle(3); booyah.print(); <<<"Create new array using HyperArray get method, print new array">>>; booyah.get() @=> float theNewArray[]; for (0 => int i; i<theNewArray.cap();i++) { <<<theNewArray[i]>>>; } } testShiz();

1 0

midi clock
by Kassen 21 Apr '06

21 Apr '06

Hi, list. At the moment I'm merrily ChucKing allong building a little "groovebox". My idea here is that it's easier to put knobs on a laptop then it is to put a comand line on a groovebox. The plan is to have one shred backed by a few sporked functions that will allow me to manipulate data in arrays using a midi controler (toggeling steps for beats, so far). Eventually this will use events to trigger the sounds in other shreds so those sounds could be re-compiled without ruining the data in the arrays. This is working nicely and seems like a good idea, even if at the moment it's not quite up to the level of a rs7000 or Live (yet!). For true groovebox functionality it would be nice to have some way of listening to a MIDI clock and this seems to be missing at the moment. Of cource MIDI sync normally works quite differently from the typical structure of ChucK code but at least some way of relating to it would be nice. I'd like to sugest some new function for this. What if we had something that would for example be able to output those midi clock "sync" pulses (I think they are properly defined as repeat "play" messages or something along those lines?) as events as well as the duration (in time) between the last two clock ticks of a incoming clock. Practically speaking it might be more sensible to average the time of -say- the last four of those, considdering how inacurate MIDI is and how quickly multiplied jitter might add up if looped. This would enable us to have chuck loops that would go something like; //wait for next sync event sync => now; //main loop while(true) { something_involving_realy_cool_beats; //advance my sequencer 1 +=> steps; (steps % 16) => steps; //advance time by a quarter note 24::click => now; } Now; this example would probably start drifting unless the duration of "click" was updated frequently by some external loop (thus averaging out the jitter) and even then some more advanced form of syncing the whole loop up every once in while would be preferable, especially if the external master clock will be modulated in mid piece.... Still; I hope this demonstrates that Chuck programs could relate to a MIDI clock in a way that's at least somewhat similar to the way they normally relate to the internal ChucK "now". Bad; Keeps MIDI alive while it realy should have died long ago. Good; Allows one to jam with friends who haven't yet realised MIDI should have been left in the 80's. Not all that complicated to implement, I imagine. Alternatively it would also be welcome to point me at where it says we allready have something like this; I looked and couldn't find a thing. Yours, Kas.

4 5