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

percussion samples for downloading?
by Robert Poor 14 Jun '09

14 Jun '09

Gang: I've been scouring the web for a source of downloadable percussion samples. I've found plenty of downloadable LOOPS, but I'm really just after individual instrument hits. And being a stingy guy, I'm hoping to find something for free. Any suggestions? - Rob

2 2

implementing a "wait for signal with timeout"
by Robert Poor 11 Jun '09

11 Jun '09

Gang: In real-time music making, sometimes you want to wait for a signal (e.g. event.broadcast()) OR for a specific time to elapse, whichever comes first. I've implemented ways to do this, but I'm not really satisfied with the code. Here's the problem: Lets say that your music is slaved to a metronome, and the metronome is allowed to change speed. You want your music to stay sync'd to the metronome. If you simply do: now + (1/tempo)::second => time next_beat; next_beat => now; play_note(); you'll be in trouble if the metronome speeds up while you're waiting: your note will be late. The fundamental problem is that once you execute "next_beat => now;", you're committed to waiting and there's now way to break out of it, short of killing the thread. The problem with killing the thread is that you leak 88K with each thread (!!!). So here's the programming challenge: how would you implement a "wait for signal with timeout" that will block until it gets a signal OR a specified time has elapsed? Since each thread costs 88K in non- reclaimed memory, you may create threads, but your solution must re- use them. As I said, I have implementations which I'm happy to share, but I'd like to see how you would do this first. Most of all, this is likely to turn into a feature request for the next version of ChucK. - Rob

5 22

Re: [chuck-users] implementing a "wait for signal with timeout"
by N. Cameron Britt 09 Jun '09

09 Jun '09

Attached is a solution I came up with for this problem that I used in my PLOrk piece this spring. I spork a "possibility" for something to happen, which waits on an event. Immediately after I spork a "timeout" shred that kills the possibility shred if the event doesn't come in time. One downside of this (I'm sure there are others I haven't thought of!) is that using Machine.remove causes stuff to print in the console. To get rid of that I piped the output to grep. From the command line run: chuck timeout.ck 2>&1 | grep -v removing Cameron

2 1

cyclone, a time-scaling metronome
by Tom Lieber 09 Jun '09

09 Jun '09

Poor's mention that he was working on a metronome reminded me that I still hadn't published mine. Then I dug it up and realized that I never published it because it was still too crappy. But it turns out the Timeout code I wrote for that thread was just what it needed! So now it's about done, save a nasty sample-rounding issue. Because of Kassen's remark about me posting things to my site but not the mailing list, I'm linking it here: http://alltom.com/pages/cyclone It's a metronome that lets you change its tempo on the fly, using it for timing like // wake me up at BEAT X cyc.at(X) => now; or // wake me up X BEATS from now cyc.wait(X) => now; although the second one is not recommended for situations when there are multiple shreds because of the sample-rounding bug I mentioned before. ChucK's timing accuracy for raising events (nearest sample) isn't good enough, I think, though I haven't actually narrowed the problem down yet... I hope it's useful nonetheless! -- Tom Lieber http://AllTom.com/

1 0

Re: [chuck-users] implementing a "wait for signal with timeout"
by Robert Poor 08 Jun '09

08 Jun '09

So as presaged, this is a schematic of how I've implemented "wait for signal or timeout". First, I have a "PermaShred" class: a call to: PermaShred.run_process(this); calls a do_process() function (which you subclass) in its own thread, er, shred. When your do_process() function returns, the shred is returned to a resource pool, making it available to the next call to PermaShred.run_process(). That's my basic mechanism for not leaking shreds. To build wait_for_signal_or_timeout(event E, time T) functionality, I spawn, er, spork a PermaShred "watchdog" that waits until time T arrives, and then does a E.broadcast(). In the meantime, the caller simply blocks on event E. As a result, the caller will return if anyone does a broadcast on E OR if the watchdog process times out. It's a bit convoluted -- among other nuances, the watchdog shred needs to be careful about signaling after the caller has moved on -- but it does the job. And it doesn't leak memory after an initial pool of PermaShred objects have been allocated. If anyone wants to see the code, let me know. - Rob

1 0

The ChucK Show
by Les Hall 08 Jun '09

08 Jun '09

Folks, I am running out of new material for the ChucK Show. I know you've got some gems you can send me, and files do transfer over this mailing list, so please send them in. Let your work be heard! I'm going to be playing more classics to flesh out the show, but we need new stuff! Thanks very much. Les (Inventor)

4 3

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

08 Jun '09

Kassen, No I haven't looked at Tom's blog. Can you link me up? Link me up Scotty, I'm running out of ChucK! Les

2 1

Details on the STEIM worskhop
by Kassen 02 Jun '09

02 Jun '09

Fellow ChucKists, STEIM put up the details for the workshop on ChucK I'll host, starting June15 here; http://www.steim.org/steim/workshops.php?id=139&b=1&r=1 People interested in getting a solid start ChucKing and within reach from Amsterdam (NL) in June might want to check that out. Please note places are limited so reservations are needed. Yours, Kas.

2 6

assignment (BUG?)
by Kassen 02 Jun '09

02 Jun '09

Fellow ChucKists, Either we have a bug or I don't understand assignment (quite possibly both are the case, I won't rule that out). Consider this; int foo, bar; foo @=> bar; //alternately, this gives the same result //bar @=> foo; 1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>; I was expecting both to be 1 but here bar is 0 (Linux, miniAudicle modified to host 1.2.1.2). The following behaves as I expect it to; int foo, bar; 1 => foo; foo @=> bar; 1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>; Before I start bothering everyone with my ideas on assignment as it applies to UGens I'd like to be clear on what assignment does exactly and whether this is proper behaviour. Yours, Kas.

5 18

Re: [chuck-users] Performing with ChucK in NYC tomorrow night
by Les Hall 01 Jun '09

01 Jun '09

Mike, That is really kewl! Thanks for the sample video, I enjoyed it. Les

2 2