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

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

15 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 02 Jun '09

02 Jun '09

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

2 2

Realtime jackd
by miquel parera 29 May '09

29 May '09

Hello I compiled chuck1.2.1.2 with the flag linux-jack, everything it's fine except when try to launch chuck in jackd realtime: example: 1. Launch jackd: $ sudo jackd -R -dalsa -dhw:0 -r44100 -p256 -S 2. Launch the chuck loop: $ chuck --loop --srate44100 3. I try to add + one file and te message in the prompt of jackd it's: scbgraph starting at chuck timed out(subgrpah_wait_fd=7,status=0,state=Runing) If jackd it's launches like this: sudo jackd -dalsa -dhw:0 -r44100 -p256 -S every work, but the effecience of jackd it' poor. One solution please....

2 1

rtaudio buffer size problem
by jo 25 May '09

25 May '09

Hi everyone, I'm trying to connect a mic via a Tascam US-122L to my mac, which works fine in other programs, however I get the following error when I do chuck --dac4 --in1 test.ck (the Tascam is nicely recognized as dac4, and the test just consists of adc => dac) [chuck]: (via rtaudio): unable to open specified device(s) with given stream parameters: ... RtApiCore: OS-X error setting the buffer size for device (TASCAM: US-122L). [chuck]: cannot initialize audio device (try using --silent/-s) I've tried all permutations of --dac, --in, --bufsize, --blocking etc. with no success. With --silent there are no errors, but of course, some sound would be nice... Curiously, when I do all of the above in miniAudicle, I never get any errors (but no sound either). I'd be grateful for any hints! jo p.s. this is the chuck --probe part chuck]: ------( chuck -- dac4 )--------------- [chuck]: device name = "TASCAM: US-122L" [chuck]: probe [success] ... [chuck]: # output channels = 2 [chuck]: # input channels = 2 [chuck]: # duplex Channels = 2 [chuck]: default device = NO [chuck]: natively supported data formats: [chuck]: 8-bit int [chuck]: 16-bit int [chuck]: 24-bit int [chuck]: 32-bit int [chuck]: 32-bit float [chuck]: 64-bit float [chuck]: supported sample rates: [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: 88200 Hz [chuck]: 96000 Hz

1 0

name that shred
by Robert Poor 24 May '09

24 May '09

Hi gang; Is there a way to give a shred a name so that MiniAudicle displays something more useful than "spork~exp" in the list of running shreds? It would be handy -- reassuring even -- to be able to see what shreds are running. - rdp

6 13

chuck under gdb?
by Robert Poor 24 May '09

24 May '09

fellow chuckers: i'm trying to track down a persistent crasher in chuck using gdb. so far i can see that it's dying with a KERN_INVALID_ADDRESS in Chuck_VM::run(), two levels below a call to RtApiCore::callbackEvent(). but what I don't remember is how to instruct gdb to associate the source files with the executable, so I can look at the actual code where it's dying. can anyone offer a refresher / tutorial on that? (and do I need to recompile the sources with -g?) - rob

2 4

Re: [chuck-users] Using FFT 'manually'
by Siepie 24 May '09

24 May '09

> Hi, Siebe! Welcome on board, IMHO there is a great shortage of Dutch > ChucKists so it's good to see you here. Thanks for your reply, Kas. I hope I can help making ChucK a bit more popular around here, I'm sure others will like the way it works. > As FFT expects to deal with complex numbers it's not so > surprising that the one using floats doesn't work. Now I'm afraid you misunderstand. The one getting complex numbers is an IFFT. >From the manual: fft.transform(float[]) //input fft, which i believe doesn't work. fft.spectrum(complex[]) //output fft, which works when using fft.upchuck() ifft.transform(complex[]) //input ifft ifft.samples(float[]) //output ifft Also, both examples run, the FFT one is just not giving any output. In my experience the VM will break and give an error when variable types don't match, so that's not my problem here. I'm currently trying to tweak around a bit with the signal chain. There the types do not exactly match, but that I could correct with a dummy IFFT (FFT fft => IFFT dummy => blackhole), also that didn't help. IMO there really seems to be a problem with he fft.transform function. I can't get it to do anything. Siebe _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 2

Using FFT 'manually'
by Siepie 24 May '09

24 May '09

Hello all, My name is Siebe, I'm a MT-student from the Netherlands. I've just started experimenting with ChucK on Windows XP a bit and I really liked how quickly I was able to get things working. For my study I might be interested using ChucK for music and audio analysis. I'm currently trying to figure out how to 'manually' work with an FFT-class, by using .transform(float[]) instead of .upchuck(). But as far as I can see, the transform function for the FFT does nothing, in contradiction with the .transform(complex[]) function for the IFFT class, which seems to work fine. Here are two examples to clear up my point: The working IFFT code: http://pastebin.com/f9b762ad The not-working FFT code: http://pastebin.com/f7a8aae08 My question is, am I doing it right? Since both examples are pretty much the same, my guess is that both should work. Is this a bug in the i386 version? Or are users with another OS experience the same? Any help would be much appreciated. _________________________________________________________________ See all the ways you can stay connected to friends and family http://www.microsoft.com/windows/windowslive/default.aspx

2 1

Performing with ChucK in NYC tomorrow night
by mike clemow 18 May '09

18 May '09

Hey ChucKists, Just letting you all know of a show in NYC. We're performing with an application that makes heavy use of ChucK for sound design sonifying blob-detection information from an openFrameworks program that munges video. The system is called "Outis" and was my masters thesis project at NYU. If any of you are in town, I'd love to put faces to names. ;-) -Mike show: http://michaelclemow.com/?p=640 outis: http://michaelclemow.com/?p=616 -- http://michaelclemow.com http://semiotech.org

1 0

Re: [chuck-users] sillyness witth file names (Kassen)
by Les Hall 16 May '09

16 May '09

Les; couldn't he have made a script that would loop over the dir and delete anything that wasn't named like any of the other files? Yours, Kas. Kas I really don't know if that would have worked, we just all thought it was kind of funny. Les

1 0

Mix2 doesn't mix?
by Tom Lieber 16 May '09

16 May '09

Documentation says Mix2 will "mix stereo input down to mono channel." But then why does this example play the sine wave in my left ear and the noise in my right? Mix2 mix => dac; SinOsc s => mix.left; Noise n => mix.right; 1::second => now; Am I using it wrong? -- Tom Lieber http://AllTom.com/

2 1

sillyness witth file names
by Kassen 15 May '09

15 May '09

Dear list, I just discovered this is a valid filename under Linux (you can still play the file by double-clicking, even); foo";Machine.crash();"bar.wav This means that this; my_buffer.read("my_file"); //gives a syntax error with the above filename is more safe to use than this; "my_file" => my_buffer.read; //this parses, then crashes with the above filename. This isn't much good for anything, aside from pointing out that there can be valid files that can't be played back by ChucK, but it's a exciting, new and especially perverse way to crash so I find that noteworthy on it's own. Happy crashes and a good weekend, Kas.

2 2

Re: [chuck-users] sillyness witth file names
by Les Hall 15 May '09

15 May '09

Not to get off topic too far, but this reminds me of a funny situation back in college. Someone had managed to create an undeletable file, and even the superusers could not delete it. I think it had a single space character as the filename and the Unix of the day didn't let you surround a filename with quotes (this was close to 20 years ago). So the file lived on eternally, lol. Another funny story from college: One day the sysop asked me for my password. I replied sharply with what sounded to him like "bite me", an obvious rude remark. He said "No, really, I need it to fix some stuff." I replied by spelling out the password: "That's the password: byteme". Everyone had a great laugh. We now return you to your regularly scheduled ChucK mailing list. Les

1 0

Diatonic tuning system
by Hans Aberg 13 May '09

13 May '09

This code now allows defining diatonic tuning systems, which once defined, selects the intervals. It is very easy to add a new tuning system: just one line. Plus adding its name were you want to have it on the keyboard. A tuning system is defined by giving intervals, which can be given in different units (ratio, log, cents), and their diatonic coordinates, plus an octave which needs not be the interval ratio 2 or be equal to 2m+5M. Intermediate pitches are supported (but at most one for the moment). Also a function that computes all ETs, plus some other illustrating tuning systems. In order to illustrate that the octave needs not the interval ratio 2, Georgian style tunings have been added, which divides the perfect fifth into four equal steps, so that m = M and the octave is slightly sharp. Plus Bohlen-Pierce scales, dividing the ratio 3 into 13 steps, with the octave 5m+4M. And the intermediate pitches are illustrated by Just intonation relative Pythagorean (might also be used for Turkish music description), Turkish E53, and Persian style tunings. So with just one neutral second added, one can cover a lot. Details: see the file. Stay tuned! Hans

3 5

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

13 May '09

Hello ChucKists! I have good news regarding The ChucK Show. We are now set up for live ChucK! That means instead of a playlist of pre-recorded ChucK mp3's, the show will feature actual ChucK programs running in real time. This allows me to do stuff like run interactive programs like Digitar, Generator, and Guitar Lab as well as play multiple ChucK programs simultaneously. I even coded up a ChucK program that uses my homemade DIY ChucK controller to permit hardware control of the microphone and I added a "Demonic Chipmunk" Vocoder to the program as well. You'll have to tune in to hear the Demonic Chipmunk Vocoder in action, it is funny! Cheers, Les (Inventor)

1 0

"pure"
by Tom Lieber 11 May '09

11 May '09

class X { fun void doit(); } [Untitled]:line(2): function declaration must contain code... [Untitled]:line(2): (unless in interface, or is declared 'pure') [Untitled]:line(2): ...at function 'doit' interface X { fun void doit(); } [Untitled]:line(2): function declaration must contain code... [Untitled]:line(2): (unless in interface, or is declared 'pure') [Untitled]:line(2): ...at function 'doit' class X { fun pure void doit(); } [chuck](VM): sporking incoming shred: 1 (Untitled)... Does anybody use "pure" or know what it does? The last example seems to be equivalent to saying "fun void doit() { }". -- Tom Lieber http://AllTom.com/

5 7

iPhone => ChucK
by Mark Cerqueira 11 May '09

11 May '09

Hi all, About a week ago I posted a message about one of many options, OSCTouch, to use an iPhone/iPod Touch as an interface device via OSC for musical performance. There were some responses on other apps that could be used, OSCemote and Mrmr, so I got all of them and played around with them. Fortunately, I also had a PLOrk final that involved creating a new instrument so I figured I might as well give it a go and see if I could get the iPhone to speak to ChucK directly. Here is the final product: http://wiki.cs.princeton.edu/index.php/PLOrk2009/MarkCerqueiraFinalProject I wrote a new class called OSCemote.ck that lets OSCemote speak directly to ChucK. The wiki page has links to the code, sample files to mess around with, implementation details, and known issues/future work. I figured some on this list could make good use of an iPhone that talks to directly ChucK. Enjoy! Any feedback on improvements/issues is, as always, very welcomed! Best, Mark

1 0