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

push but no pop?
by Robert Poor 13 Apr '09

13 Apr '09

This note contains a coding tip, a feature request and a bug report. In that order. CODING TIP: Resource pools are a simple way to avoid memory allocation. This should be old hat to veteran coders, but I remember thinking this was a cool technique when I first saw it. This is important in embedded systems (that lack malloc()/free()) and also in ChucK (which doesn't GC heap-allocated objects). The concept is simple: you keep an array (a "pool") of available items. When you want an item, you take one out of the pool, or create one if the pool was empty. When you're done with the item, you just chuck it back in the pool for the next time someone wants it. The code is simple. Let's say you created some structure, like a NoteEvent, that you'll be using heavily in your ChucK code. By "heavily", I mean you'll be creating thousands of these every second: public class NoteEvent { float frequency; float commercial_potential; int makes_adults_complain; } How do you keep ChucK's memory from getting silted up? Use a resource pool. Here's the code. NoteEvent @ _noteEventPool[0]; fun NoteEvent allocateNoteEvent() { null @=> NoteEvent @ noteEvent; if ((_pool.size() => int size) > 0) { // pop a NoteEvent from the end of the _pool, if available _pool[size-1] @=> noteEvent; size-1 => _pool.size; } else { // the pool is empty, create a new one new NoteEvent @=> noteEvent; } return noteEvent; } fun void freeNoteEvent(NoteEvent @ noteEvent) { // push noteEvent onto the pool so it's available for the next // call to allocateNoteEvent(). _pool << noteEvent; } Call allocateNoteEvent() when you need a noteEvent, call freeNoteEvent() when you're done with it. You're responsible for freeing them when you're done with them -- it's not automatic -- but if you free each event that you allocate, ChucK will not allocate any memory above what' needed. FEATURE REQUEST As written, array's popBack() function has a void return. It would be nice if popBack() returned the element it removed, so we could write the code like this: fun NoteEvent allocateNoteEvent() { null @=> NoteEvent @ noteEvent; if (_pool.size() > 0) { _pool.popBack() @=> noteEvent; } else { new NoteEvent @=> noteEvent; } return noteEvent; } BUG REPORT This may be operator error rather than a bug, but the following code: fun Element allocateElement() { if ((_pool.size() => int size) > 0) { _pool[size-1] @=> Element @ element; size-1 => _pool.size; return element; } return new Element; } reports: chuck(20184,0xa018a830) malloc: *** error for object 0x5eb6e0: double free *** set a breakpoint in malloc_error_break to debug I think the problem may be in "return new Element" -- it may be trying to return the Element itself, rather than a reference to the Element. If that's the case, though, it seems like something that should be caught at compile time. - Rob

3 2

SndBuf.read() BUG & feature request
by Kassen 12 Apr '09

12 Apr '09

Fellow ChucKists, I was trying to detect the successful loading of a wave file, hoping that SndBuf.read() wpuld return "true" upon successfully opening a file like when opening a HID device and "false" otherwise. Instead it turns out that the following code seg-faults. SndBuf foo; <<<"kick.wav" => foo.read>>>; Aside from how this means losing the whole VM, which is bad, such functionality would permit for the implementation of search-paths. For example; when a relative location doesn't work we might want to append the file-name to a string expressing the absolute location of some directory filled with samples. Yours, Kas.

1 0

Audicle on Ubuntu
by Beinan Li 11 Apr '09

11 Apr '09

Hi ChucKers, I tried the latest Audicle on my Ubuntu 8.04, building was a breeze, but I found problems: 1. Conflicts with Compiz-fusion: When the compiz-fusion visual effects are turned on, Audicle GUI's redraw looks really confusing: I can see other APPs bleeding through Audicle here and there. Also, moving the window only expands its size. Remove the system visual effects and it appears normal again. 2. Trying to kill the Audicle window with the system "Force window to quit" tool caused system crash. This happened with or without Compiz. Beinan

1 0

The ChucK Show
by Les Hall 10 Apr '09

10 Apr '09

Hey folks, The ChucK show was a big success this week. None of the technical problems of last week, and I was properly caffeinated prior to the show, lol, so I was nervous but did well. The microphone on the eMac is much better than the one on the Acer netbook (though I lub my wittle netbook), and playing recorded ChucK was WAY easier than doing live ChucK with Reaper and a cable between two computers, dang. Although Blue_Hell lost his recording and I didn't record, there will be plenty more shows to enjoy. We had 9 listeners at one point, and I even did a "featured ChucKist" of Kassen this week... Please send in your ChucK programs or recordings, we need them for the show. I will announce some historical info about each song if I can, so just fill me in. email ChucK Show content to me: inventor-66(a)comcast.net. Don't make me search out the web for ChucK music, lol, because you know I will if I have to! :) :D Thanks, Les (Inventor)

1 0

Re: [chuck-users] The ChucK Show
by Les Hall 09 Apr '09

09 Apr '09

On Apr 8, 2009, at 12:00 PM, chuck-users-request(a)lists.cs.princeton.edu wrote: > Les, > Good luck with this. Sounds like fun. > > Maybe after you've been at it awhile you'll consider a live show or > live segment once in awhile Chaos is fun and good for the soul as long > as it isn't a way of life. That would be 'touring rock and roll'! ;-) > > Cheers, > Mark Mark, Thanks and will do, it would be fun go go live again but I really need to get my act together first. I'm kinda running out of live material for now anyway, but hopefully I can get some code from the wiki or something. I don't care if I have to repeat stuff, I'll just mix it up and go from there... Les

2 1

timestamps, NetClock.
by Kassen 09 Apr '09

09 Apr '09

Fellow ChucKists, I've been quite interested in NetClock ( http://netclock.slab.org/wiki/index.php/FAQ ) lately, after some posts about it on the TOPLAP list. To quickly summarise; the idea is fairly similar to MIDI clock, except to sync the open source performance programming languages (SC, PD, Fluxus Perl (because of feedback.pl) and -hopefully- us). NetClock uses OSC messages, combined with syncing system time to a time-server, to create a clock shared by all participants. The participants can all change things like the central BPM so in that sense it's quite different from and a lot more democratic than MIDI clock. This would be interesting for colaborative livecoding across systems (currently hard to sync without agreeing on a protocol prior to the performance) or to sync homebrew sequencers, generative processes and so on. The good news is that we could implement the whole standard (as far as I can see) in ChucK already and have it as a public class, perhaps as a prototype stage if we would elect to make this a part of the language. A simple class extending Event and two or so sporked shreds would do the trick. The bad news is that this would need time-stamps for OSC messages which we currently lack. This is where I thought things would get tricky; ChucK has very much it's own ideas about time that are quite independant of the system clock (aside from the soundcard's clock) and bringing the two together might get tricky, I feared. After giving it some thought I feel that maybe the best solution might be to get the system time at the birth of the VM and store it. From there on OSC timestamps could be offset by this, creating user accesible timestemps that are purely in terms of ChucK's time. As far as I can see this would open the posibility for timestamps without any big conflict in ways of timekeeping or the need for much aditional syntax in user space. It doesn't sound too involved as a feature either (to me, right now; I might be missing stuff). So, the question now (mainly to the dev's) is; does this make sense? Are there fundamental reasons why we aren't yet supporting OSC timestamps? If so, could we as a user groups take a look at those and see whether they could be dealt with in a coherent way? I can't be the only one who would be very interested in convenient jamming with my friends who run SC or PD? Yours, Kas.

1 0

Re: [chuck-users] The ChucK Show
by Les Hall 07 Apr '09

07 Apr '09

On Apr 7, 2009, at 12:00 PM, chuck-users-request(a)lists.cs.princeton.edu wrote: > > > Is there a podcast/downloadable version I can get hold of? > > As I am in the UK, 11pm - 1am is a bit of a difficult time for me. > > I never did finish any of the chuck things I started, but getting them > on the radio might (I say might) give me inspiration to finish them > off. :-) > > ttfn, > > Adam > Adam, Archives of The ChucK Show are available at the following web site: http://bluehell.electro-music.com/_streams/2009-03-01/ That link is temporary and may change. The good news is that, after the chaos of last week I decided to change my setup for the show. I'll be playing prerecorded mp3 files of ChucK music instead of doing live ChucK, which greatly simplifies my setup. So hopefully the next show will go a little smoother. Take care, Les

2 1

Re: [chuck-users] The ChucK Show
by Les Hall 07 Apr '09

07 Apr '09

Hi folks, This week the ChucK show was a mess, heh! It started out with technical difficulties and choppiness which eventually got better, though my recording has gaps all through the show. The good news is that I'll be improving things by rebooting the machines before the show and testing before the show, plus buying a decent mic and a nanokontrol for the sliders. But we all recognize that we are new to this and such problems are inevitable. I'd like to ask for code submissions as we will be running out of material in a week or two. You can email code or recordings to inventor-66(a)comcast.net (that's me). Thanks and have a great week! Les

3 2

memory exhausted
by Gregory Brown 05 Apr '09

05 Apr '09

Hello all, I have written a script that uses a rather data file to generate a chuck file that is about 24000 lines long and 564KB. When I run the script I get a "memory exhausted" error. Are there chuck-imposed limits that I am running into? Is there a way to allocate more memory to chuck? I have tested this on two machines, both running OS X, ChucK 1.2.1.2, 2GB of RAM. It does not seem to matter what other processes are running or how much memory is available (real or virtual)… it always exits at the same line. Also -- when I cut the file down to a few thousand lines, it runs fine. Any thoughts would be great. Thanks, - Greg

2 3

segmentation fault / OSC
by Bozelos Dimitris 04 Apr '09

04 Apr '09

Hi again guys, I've run into some more problems in my brief acquaintance with ChucK (although it's definitely fun!). For some reason I constantly get a "segmentation fault" fatal error sometimes just after some seconds I run my shreds. What does this mean? I do something that might be silly, I send/receive parameters between shreds using OscEvents, can this cause the problem? Is there another way of communicating (exchanging control signals in this case) between processes? Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error. Is there a buffer or a limit on the messages you send / receive? Can I somehow declare global variables? I checked the documentation and I didn't find anything. If the problem is because of excessive use of OSC I could maybe read/write global variables. Cheers, Dimitri ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

4 7