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

record audio directly into sndbuf?
by Matt Diamond 18 Mar '09

18 Mar '09

My apologies if this question is silly, I'm a bit of a programming amateur... I'd like to create a patch wherein I could record a few seconds of audio from the adc (mic input), then play random segments of that audio back. Seems simple enough, but I'm having trouble mastering the art of recording sound in ChucK. Ideally, I'd like to use sndbuf to store the audio in a temporary buffer, though I'm wondering if my only option is to use WvOut to write the audio to an actual file. I'm not even doing very well using WvOut to record... I'd like the recording to be triggered by a button toggle (or even just triggered by a normal button with a set recording duration). I think I'm fairly comfortable with the MAUI button object, but I'm not sure how to implement triggered recording. I've seen examples that merely set up an adc => WvOut w => blackhole configuration, then tell the program to just do this for 5 seconds and then close the file, but I'd like something where I could have the shred running, and then activate a recording process when the button is pushed. I've tried implementing this with a while (button.state()) loop inside of an infinite time loop, but it usually ends up crashing. I also thought I saw something about a w.record operation in the ChucK wiki, but I didn't see anything about this function in the documentation. Anyway, sorry that this is so unfocused... I'm just not sure how to even start approaching the problem. Bottom line: can I use sndbuf to record live audio, and if not, how can I use WvOut to do this? Thanks, Matt Diamond

2 2

Live ChucK-gig in Copenhagen
by Atte André Jensen 18 Mar '09

18 Mar '09

Hi On the 21. march I'll be performing at Krudttønden, Serridtsslevvej 2, in Copenhagen at 21:00 with my meditative, electronic project, "Modlys". Heavy use of ChucK in a more pop-ish setting than I suppose the average ChucK performance. Lots of realtime algorithmic compositions and improvisations. Examples of how it sounds (not live): http://modlys.dk/mp3/holde_pkt.mp3 http://modlys.dk/mp3/i_ly_af_dig.mp3 http://modlys.dk/mp3/stille_hvisken.mp3 The lineup is: Atte André Jensen (me): Laptop/ChucK w gamepad + synth + melodica Britt Dencker Jensen: Vocals David Blomqvist: Double bass André Chercka: Live video Anyone in the area are more than welcome, the entré is DKK 50,- -- Atte http://atte.dk http://modlys.dk

9 26

ChucK Soft Studio Mixer
by Les Hall 18 Mar '09

18 Mar '09

Hi, I would like to run separate ChucK programs and combine their audio streams with a ChucK mixer program. To do this, I would send each audio output to dac.chan(n), where n could be a large-ish number like 8 or 16 or something like that. Then I would write a mixer program that combined these separate audio streams into just dac.left and dac.right, with adjustable gain/attenuation on each channel and an n-to-2 switch matrix. Sounds good, but when I try it I am only able to use the physical dac channels that I have with are dac.chan(0) and dac.chan(1). In other words, I am disappointed to learn that there are no virtual dac channels. So now I'm not sure if what I really need is a physical multi I/O USB interface or maybe a hardware mixer or whatever. How can I route multiple signals within ChucK between processes? Seems like this should be easy to do... OSC? I dunno, enlighten me please. Thanks, Les

3 2

recycling program
by Robert Poor 18 Mar '09

18 Mar '09

Are there tools or techniques for monitoring memory allocation in ChucK? I've been stress testing my code, and after about five hours ChucK vm stops with a malloc / mmap failure. It would be nice to figure out what's clogging memory. [In a previous life, I was an embedded systems programmer, so I'm happy to create reusable object pools and managing the objects myself, but I need to know what leaks and what doesn't.] On a related note, I notice that ChucK uses the standard library malloc rather centralizing calls through a single chuck_malloc() (or the existing checked_malloc()). Going through a single call would make it easier to monitor heap allocations. Just my $0.25. - Rob

4 5

3-Axis USB Accelerometer with I/O
by Les Hall 18 Mar '09

18 Mar '09

Huh, funny that you folks were posting about controllers, it just so happens that the Ultimarc controller is now ready for sale. It's $49 and you can see it at the following link: http://www.u-hid.com/index.php? option=com_content&view=article&id=21&Itemid=24 I can't be impartial because I will receive a small part of the net profit of these boards. That's because I approached the company with the idea and much to my surprise they decided to work with me on developing the product. They also sell other controllers. This one, the U-HID-G has a 3-axis accelerometer on a USB interface plus an expansion port for pots, switches, slow analog in, etc. What I like about this device is that it looks like a joystick to the computer, so there's no need for drivers or special interface programs or huge sections of ChucK code, etc. It interfaces to ChucK easily. The only downers I see are 1. it is wired, not wireless, and 2. it requires a PC for configuration because the config utility is a Windows application. So basically it's another choice among many. Kassen, did you get one in the mail? I thought Andy sent you one. Cheers, Les Hall (Inventor)

3 2

Wii Controllers for ChucK
by Robert Poor 17 Mar '09

17 Mar '09

I suspect this has been covered -- and I see hints on the ChucK forums and archives -- but I want the latest word: can you use a Wii controller as a controller for ChucK running under OS X? I would *love* to control ChucK without laying a hand on a keyboard (either laptop keyboard or MIDI keyboard), and the Wii seems like a good bet. On Amazon, the Wii Remote Controller is selling for $36: http://www.amazon.com/Wii-Remote-Controller-nintendo/dp/B000IMWK2G/ref=pd_b… I'd buy one in a heartbeat if someone told me if there was an easy path between the Wii remote and ChucK HID messages. Thanks. - Rob

1 0

Shred Utilities: waitWithTimeout()
by Robert Poor 16 Mar '09

16 Mar '09

Here's a small module I wrote mostly out of necessity and feel it's my first bit of ChucK code worth submitting to a library repository. I checked out lick (http://github.com/heuermh/lick/), but noticed that all code there was written by heuermh and felt that maybe this wouldn't fit into lick's Grand Scheme. So I'm not sure where to send it except to this list. Comments, suggestions are welcome (but go easy on me -- I'm new to ChucK!). Thanks. file: ShredUtilities.ck /* ================================================================ Shred Utilities for the ChucK programming language Copyright (c) 2009 Robert Poor. All rights reserved. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/ >. ================================================================ */ // ================================================================ // File: ShredUtilities.ck // // Description: ShredUtilities extend the basic shred (thread) mechanism // with waitWithTimeout() methods. // // Author: Robert Poor <r(a)alum.mit.edu> // Date: March 2009 // ================================================================ public class ShredUtilities { // waitWithTimeout(Event e, time t) - Block execution of the // caller's thread until event e receives a signal or time t // arrives, whichever comes first. // // Implementation: spawn two threads, one to wake us when event e // receives a signal, the other to wake us when the appointed time // arrives. Pass both threads a common event 'union' on which to // notify this thread, then block on union. // fun static void waitWithTimeout(Event e, time t) { Event union; spork ~ _waitForEvent(e, union) @=> Shred @ eventWaiter; spork ~ _waitForTime(t, union) @=> Shred @ timeWaiter; union => now; eventWaiter.exit(); timeWaiter.exit(); } // waitWithTimeout(Event e, dur d) - Block execution of the // caller's thread until event e receives a signal or d time // has elapsed, whichever comes first. // fun static void waitWithTimeout(Event e, dur d) { waitWithTimeout(e, now+d); } // ================================================================ // internal helper functions // wait for an event on e, unblock event union. fun static void _waitForEvent(Event e, Event union) { e => now; union.broadcast(); } // wait for time t, unblock event union. fun static void _waitForTime(time t, Event union) { t => now; union.broadcast(); } }

1 0

WarpTable inconsistency
by Kassen 16 Mar '09

16 Mar '09

Dear Dan, WarpTable seems to have a issue where .lookup() doesn't behave like scanning it with another UGen does for values slightly less than 1. I think the scanning feature is wrong here, at least scanning doesn't behave according to the docs. Consider this example that uses WarpTable as a wave-shaper on a sine wave; ======================== SinOsc s => WarpTable wp => dac; //some trickery to offset and scale the input Step st => wp; .50 => st.next; //notice this line; .5 should be fine here yet isn't //increasing this to .5 will cause artefacts .4997 => s.gain; //scale the range back and avoid DC offset Step stInv => dac; -.1 => stInv.next; 2 => wp.gain; 200 => s.freq; //increase the second value for "drive" //this is the bit that's actually useful and interesting here //in this case we keep it linear to be able to hear the artefacts more clearly. wp.coefs([1., 1. ]); minute => now; ========================= Or; to demonstrate the exact same issue in it's most extreme case; ============== Step s => WarpTable wp => dac; //linear wp.coefs( [1., 1. ] ); //UGen based index 1 => s.next; //allow for the value to be updated samp => now; //both should be 1.000000 <<<wp.lookup(1)>>>; <<<wp.last()>>>; ===================== I believe this to be a error. Additionally; the various Gen UGens would be a lot easier to use for wave shaping if they could have a mode where they would get indexed from -1 to 1 and output the same range; this would avoid the need for Step ugens and setting gains to compensate like in the top example above. Right now they can only be indexed usefully by things like Phasor and Envelope and chaining a few can yield interesting phase distortion effects using Gen10 but using them in the amplitude domain is quite inconvenient, even when they would make a lot of sense there. Maybe this would be worthy of consideration, especially as some of the pages referenced by the Gen docs do hint at this usage as well. Yours, Kas.

2 2

small docs/web-page note
by Kassen 15 Mar '09

15 Mar '09

Fellow ChucKists, I'd like to suggest we note ChucK's inability to run on 64 bit platforms on the download page. I feel this limitation is under-documented, particularly compared to the relative availability of 64 bit processors and OS's (especially Linux). This turns out to lead to confusion and disappointment; a single line on that page would save people the effort of downloading, compiling, troubleshooting and finally posting to the list or forum. There have -of course- been list topics on this limitation, as well as some effort to remidy it; most of us will be aware of that but this isn't clear to potential new users who aren't -yet- on this list. It's a very minor issue but IMHO it doesn't reflect well on us to not point this out. Yours, Kas.

3 4

time goes backwards (and I don't like that)
by Robert Poor 14 Mar '09

14 Mar '09

I can make time go backwards. Here's the file: ========================= Event _e; time _t; spork ~ beatProcess(); while (true) { now + 1.00001::second => _t; _e => now; <<< "returned from _e => now at", now >>>; } fun void beatProcess() { while (true) { _t => now; <<< "broadcasting at", now >>>; _e.broadcast(); me.yield(); } } ========================= And here's the output: ========================= bash-3.2$ chuck foo.ck broadcasting at 44100.441000 returned from _e => now at 44100.000000 broadcasting at 88200.441000 returned from _e => now at 88200.000000 broadcasting at 132300.441000 returned from _e => now at 132300.000000 ========================= The "while(true)" shred sets _t to the time at which it wants to be woken up. Note that (intentionally) the increment is slightly over a second. It then blocks on event _e. Meanwhile, the beatProcess() shred blocks until the time in _t, then triggers event _e to resume execution of the while(true) shred. What happens: - the beatProcess shred triggers _e at time 44100.441000 - the while() shred returns from its wait at time 44100.0000 One might think that the while(true) shred woke up *before* _e got triggered, but Apple isn't yet building computers with tachyon technology. Can someone tell me what's really going on??? Failing that, know any doctors who will prescribe a selective serotonin reuptake inhibitor to keep me from tearing my hair out? Thanks. - Rob

3 11