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

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

more miniAudicle things
by Atte André Jensen 10 Jun '07

10 Jun '07

Hi There are a few more things regarding miniAudicle that would be nice (I'm on linux BTW): 1) When opening a file the focus should be directed to the edit area. Now it's just at the window, which means you have to click in the text area before you can type. Almost similar: Accessing save as (or save for unsaved file) leaves focus on I-don't-know-what, whereas is should go to the file name field in the dialog. 2) The native linux cut'n'paste by select and middle-click would be appreciated. Also thinks like ctrl-k (kill line) and ctrl-y (yank from kill buffer) would be great. They might take on another form, but a copy/paste without touching the mouse or some sort would be nice. 3) I think pressing tab in the editor should always mean "indent current line to relevant intention". I looked at OnCharAdded in mAView.c, but it seems that tab presses are never showing up in event.GetKey(). I'm not really famliar with cpp/wx (I did however work a bit with wxPython) but maybe it's a instantiation flag for the window or something. Unfortunately I wasn't able to figure out how to get tab to show up in GetKey. Maybe someone here (Spencer ?) knows how? If so, I think getting tab to behave as I suggest would be possible even for me :-) -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions

2 1

two gui wishes for miniAudicle
by Atte André Jensen 10 Jun '07

10 Jun '07

Hi (I'm back after too long) I have two minor requests for the mini: 1) Make the char position avaliable somewhere, so that when you get "line(2).char(12): syntax error" you know where to look. Even better (and not so minor) would be if were possible to click on the error in the Console Monitor and the cursor in the editor would jump to the correct location (or possibly jump to the first error automatically). 2) keyboard shortcuts for switching between tabs in the editor. -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions

5 7