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

NullPointerException
by eduard aylon 07 Aug '07

07 Aug '07

Hi list, I am trying to make a list of objects where each object has references to other objects, but I am not succeeding and I get a NullPointerException. The piece of code below may represent what I am trying to do. class object { Std.rand2f(0., 1.) => float f_; } class Item extends object { 2 => int size_; object item_[size_]; fun void print() { for( 0=>int i; i<size_; i++ ) <<< "item [",i,"]", item_[i].f_>>>; } <<<"----------------------------------------------">>>; <<<"calling print from within class definition">>>; <<<"----------------------------------------------">>>; print(); } 4 => int n; Item l[n]; // no problems up until here <<<"----------------------------------------------">>>; <<<"calling print from outside class definition">>>; <<<"----------------------------------------------">>>; for( 0=>int i; i<n; i++ ) l[i].print(); //offending line After execution I get: [chuck](VM): NullPointerException: shred[id=1:test.ck], PC=[37] Excuse me if it's too obvious, but I can't see why it rises the null pointer exception. Any ideas? thanks in advance, eduard

5 10

chuck~ v1.1 (universal binary)
by garton＠columbia.edu 28 Jun '07

28 Jun '07

Everyone -- Version 1.1 of the [chuck~] Max/MSP object is available for free download: http://music.columbia.edu/~brad/chuck~/ for Macintosh OS X (universl binary). This is now consistent with ChucK 1.2.0.8. [chuck~] imbeds the ChucK music-programming language in Max/MSP, bringing a sophisticated set of synthesis and signal-processing tools into the Max/MSP environment. [chuck~] also features an advanced timing and scheduling system in addition to a functional-style programming interface for algorithmic operations. Full source for the object and the language are also on-line. No Windows XP version is available at present -- sorry! This is a fun object -- enjoy it! For more information about ChucK, visit the ChucK web page: http://chuck.cs.princeton.edu/ Brad Garton Columbia University Computer Music Center http://music.columbia.edu/~brad

1 0

Gen10.coefs abuse?
by Atte André Jensen 26 Jun '07

26 Jun '07

Hi In my eagerness to play with GenX I coughed up the following code: Phasor osc => Gen10 g10 => dac; int i; [1., 0.5, 0.3, 0.2] @=> float a[]; 440. => osc.freq; while(true){ for(0 => i; i< a.cap(); i++){ Std.rand2f(-.1,.1) +=> a[i]; if(a[i] < 0 || a[i] > 1) { Math.round(a[i]) => a[i]; } } g10.coefs(a); 50::ms => now; } Fortunately the update is glitch free, unfortunately it seems that coefs() is a fairly expensive function :-( I realize that GenX might be supposed to be used with static coefs, but the above seems like it holds a lot of potential. It there a way to to what I do more efficiently or am I simply not supposed to do this? -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions

2 1

Rhodey.noteOff
by Kassen 23 Jun '07

23 Jun '07

Hi, list! It seems that Rhodey needs some attention. When I make it sound, using 1 => rhodey.noteOn; then let it sound it's fine (and decays on it's own like it should) but when it gets a 1 => rhodey.noteOff; before it has decayed it will instead drone on forever at it's current timbre and volume. 0 => rhodey.noteOn; does work, if a little abruptly. This is unlike the behaviour of the other STK fm-based instruments so I think it's a bug. It sounds to me like the issue is in envelope behavour as Rhodey normally keeps evolving it's sound over the cource of a note but once it gets stuck it stops evolving, aside from what I think is the LFO. I just checked Wurley for completenes's sake and Wurley has the same issue. BeeThree, for example, is fine, as is HevyMetl. Yours, Kas.

1 0

ChucK on 64-bit Linux, bad news
by Ken Restivo 23 Jun '07

23 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alas, the hack I was going to do will not work, and ChucK is out of the picture for me until the ChucK developers are able to make it 64-bit clean. I was planning to build JACK in 64-bit and 32-bit versions and then build ChucK in 32-bit mode and link it against the 32-bit versions of the libraries, and thus have ChucK use 32-bit libraries to converse with the JACK server and all the other 64-bit softsynths and audio applications. But I have been told by one of the JACK developers that this would not work anyway, because you can't have 32-bit and 64-bit apps conversing with the same JACK server. There are pointer-size fixes they could do to enable this, but not too many people clamoring for it, so it's low priority. I'm told that it is possible to run ChucK on a 64-bit Linux system, by turning it into a 32-bit system: one would have to build an entire 32-bit chroot environment, including *all* audio apps, and run *all* the audio apps, and JACK itself, in 32-bit mode. I ain't going there. Cool language, though. I'll revisit it a couple years from now, and see how it's progressed. - -ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGdrrYe8HF+6xeOIcRAgMUAKDI9qhdQt8G/vO3tK/HT2h/7N+JzACeJDMn g9o/sPK5BTMMxoKzqajG/0s= =zA+/ -----END PGP SIGNATURE-----

3 2

sndbuf cleanups?
by James Hughes 23 Jun '07

23 Jun '07

I've got a chuck app that runs great for about thirty minutes and then starts acting flaky. Sound starts cutting out, gets progressively worse, and then within about five minutes it ceases to make any sound. It doesn't crash, it just stops making sound. When I fire up Activity Monitor (OS X) to see what's going on, there doesn't appear to be anything obvious. Memory usage climbs steadily over the 30 minutes but caps off at around 25-30 megabytes. CPU never really gets above 75% (out of 200% on my dual core computer). The application is kind of complicated, but essentially it starts up 6 shreds, each in control of their own SndBuf. Here's a quick overview of what each shred does: Request a file name from another app via OSC Load the wav file into a SndBuf Play it for a little while (<10 minutes), skipping around in the file (mostly rewinding to the beginning of the clip). Request a new file name (repeat) The sound files are 30-150k each. It cranks through over 100 sound files before problems start happening. It doesn't look like garbage collection ever happens, but it's not using that much memory. Here's the relevant bit of code that takes the OSC message and loads up the clip: oe.getInt() => int player; oe.getString() => string snd; // allocate a new sound buffer new SndBuf @=> newClip[player]; // stick the new sound in the new sound buffer snd => newClip[player].read; Anyone have any idea what's going on? Should I be destroying these SndBufs more explicitly rather than just dropping their references? The manual says memory management is automatic, but mentions something about garbage collection not being implemented quite yet. That's ok since I can restart the chuck process every once in a while, but I need to get at least a two hour performance out before I restart. If you're curious, here's a link to the project writeup (a little out of date these days): http://www.virtualjames.com/mechatronics/final-project.html Thanks, James

3 2

SndBuf causes hickup
by Atte André Jensen 23 Jun '07

23 Jun '07

Hi I have (and have had for as long as I can remember) problems with SndBuf. I'm pretty sure the trouble is when loading a sample, then there will most often be a small but very noticeable hickup. It's quite bad with larger samples but also there with even small samples. Generally; the larger the sample, the greater the hickup. The problem seems to be gone or almost gone when the sample has already been loaded once, but this might be due to caching in the underlying os. I've tested with both alsa and jack, and all kinds of combinations of buffersizes and what have you, but although the problem seems the vary a bit (in an unpredictable pattern) it's always there. I also tested both syntaxes ("sample" => s.read and s.read("sample")), however only with wav files. I also tried both in miniAudicle and commandline chuck. Needless to say this makes SndBuf useless on my system :-( Is this a result of me doing something wrong or a bug in chuck? In any case is there anything I can do to remedy this right now? If it's a bug, I'd be most happy to help in any way I can with getting it fixed as soon as the developers time permits. BTW: This is under linux (debian/stable) on a IBM T41, 1.6Ghz, 1G ram and 7200 RPM HD. The system is running with a realtime patched kernel and is capable of playing back 20+ tracks in ardour with effects + various soft synths running along in realtime without a single xrun or glitch. Here's a simple example of something that shows the problem: http://atte.dk/download/sndbuf_test.tgz. First run shaker.ck, then after a while add substitution.ck (a beat => big hickup) or sd.ck (a snare drum => small hickup). -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions

8 15

MIDI channel / Interfaces / Machine.Remove /
by mieslings＠i12.com 17 Jun '07

17 Jun '07

Thanks, Kassen, for your reply. >...This is asuming you meant "device" above, not "channel", the MIDI >chanel would be in the message. Yes, sorry, my mistake - I meant device. >Hope that helps at least a little, not sure what you are after here, exactly. It does and I probably wasn't clear. I'm curious to know if, when a shred terminates, there is a way for the application to be made aware of it. For example, there could be a onShredExit(Shred@ shred) callback function automatically called by ChucK just before the shred terminates whose content would be left at the discretion of the user so that for instance s/he could write some code to notify all the objects dependant on this shred. But I guess there would be potential scope issues... What about functors or some sort of pointers to functions and member functions? Now, that would be really great! Mies

2 1

MIDI channel / Interfaces / Machine.Remove / Functors (!)
by mieslings＠i12.com 17 Jun '07

17 Jun '07

Hello - this is my first post here but I've been experimenting with ChucK for quite a while, and have a few questions I can't manage to find the answers to by myself... I'm more familiar with the likes of OpenMusic or MaxMSP but enjoy the power of the ChucK language as well as the fact that all it requires is chuck.exe!!! (and the manual ;) 1. Is there a way to retrieve from MidiIn/MidiOut objects the channel originally passed to open or do I need to encapsulate open in a method of my own in a derived class? (I would override open but with super not implemented yet, I don't know how to call the implementation of open in the superclass) 2. If I'm not mistaken, ChucK only accepts single inheritance; are you (the language designers behind ChucK :) planning to implement some sort of mechanism similar to Java/.NET interfaces? I've implemented a dispatching mechanism for MidiIn (so that I don't have take care again and again of the synchronisation issues etc. and have a simple, reusable mechanism to map say a note on message with some onNoteOn callback each time I use MidiIn). I now would like to generalise it and I don't know how without multiple inheritance/interfaces... 3. Machine.remove(shred.id()) terminates a shred (great feature!) but could someone clarifies what happens behind the scene? In particular, is there a callback method automatically called when a shred exits that users could hijack to perform some cleanup? 4. Finally, does ChucK support functors (perhaps even through some clever mechanism to the same effect)? Mies

2 1

multispork
by Atte André Jensen 10 Jun '07

10 Jun '07

Hi I'd really like to be able to group shreds, making it easier to have several shreds start/stop at the same time. First I'd like to hear how others address the problem... Then I thought about some possibillities: 1) Using Machine.add/remove. This is easy if I use Machine.add to spork everything, but first replace (in miniAudicle) doesn't work with shreds sproked from Machine.add. Secondly shreds added from miniAudicle can't be removed from Machine.remove (since that function requires a function). The best solution would be if Machine.remove accepted a string, in which case it would remove all shreds with that name. To complete everything miniAudicle should be able to remove and replace shreds added from Machine.add. 2) Some more fancy sporking mechanism could be added to miniAudicle. I think this has been brought up before (correct me if i'm wront), and although it would be nice, it might be difficult to implement something flexible enough for everyone. For instance I would "need" an add-list (spork these if not running) and a remove-list (remove if running) both associated with a group. -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions

2 1