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

FLOSS (user editable) manual for ChucK
by Tomasz Kaye's brain 11 Jan '10

11 Jan '10

Hi all. I noticed that there doesn't seem to currently be a user editable version of the ChucK manual online (http://wiki.cs.princeton.edu/index.php/ChucK/Manual this page is the nearest thing i found). While learning things there have been a few cases where I thought small changes to the manual wording would make things clearer (for instance my recent question about how Envelope works). I wondered about moving a copy of the ChucK manual to FLOSS Manuals, where it can be edited by users. http://en.flossmanuals.net/flossmanuals. I used this site in a recent Ardour booksprint I took part in. It's not perfect (sometimes navigation is a little unintuitive), but works well. It uses version history (different versions can be compared too). A user is appointed as a maintainers of a particular manual. Chapters can be edited by anyone with a FLOSS account, but maintainers get to decide when new versions of chapters are 'published' (made visible in the canonical version of the FLOSS manual, the one that guest visitors to the FLOSS manuals site will see) http://en.flossmanuals.net/FLOSSManuals/Maintainers . A few preliminary questions about the idea: @Ge: would you be okay with the current manual being copied to another site, and edited? (i couldn't find license details on the current manual). What do people think of this idea in general? Would people use it? Would it greatly confuse matters to have one more url for ChucK documentation? (any other issues?)

9 58

chuck 1.2.1.3 weird debug messages and aggregate devices
by mike clemow 06 Dec '09

06 Dec '09

Hi, chuck version: 1.2.1.3 (dracula) exe target: mac os x : intel I'm having trouble getting Chuck to not segfault using aggregate devices (only when trying to use more channels than in the first device) in Mac OS X 10.6. Has this always been an issue? Working around this for now, however, I'm curious what others' experiences have been with aggregate devices. Also, what's with the malloc messages in my newly compiled-from-source 1.2.1.3? Again, curious... Best, Mike -- http://michaelclemow.com http://semiotech.org

2 2

Semaphore class: wait for timeout or signal, whichever comes first
by Robert Poor 29 Nov '09

29 Nov '09

All: Based on some ideas originally by Tom Lieber, here is a Semaphore class that makes it easy to wait for a specific time OR for an external signal, whichever comes first. I've been using it extensively in my real-time performance code and would like to believe it's well debugged. Presented here in case anyone else might find it useful. Comments, questions welcome. Best, - Rob Poor // semaphore.ck -- wait until a specific time arrives or an external // signal is generated, whichever comes first. // // Sample Usage =================================================== // class TickleSignal extends Object {} // TickleSignal tickle_signal; // Semaphore semaphore; // // repeat(10) { // now + 2::second => time test_end_time; // spork ~ tickler_proc(); // semaphore.wait_for(1::second) @=> Object @ cause; // <<< "semaphore woke due to", cause.toString() >>>; // test_end_time => now; // } // // fun void tickler_proc() { // Std.rand2f(0.0, 2.0)::second => now; // semaphore.signal(tickle_signal); // } // ================================================================ // Author: Robert Poor <rdpoor(a)gmail.com>, November 2009 // TimeoutArrived is used as the <cause> argument for signal() when // the semaphore wakes due to timeout. While it's not neccessary to // define a custom class -- any object can be used as the <cause> // argument to signal() -- a custom class has the nice property that // .toString() will print out the class name. See Sample Usage above // to see how a custom class may be used as the argument to signal(). class TimeoutArrived extends Object {}; // ================================================================ // ================================================================ // The Semaphore class supports waiting for an external signal or a // timeout. public class Semaphore extends Event { // ================================================================ // class constants // TIMEOUT_ARRIVED is a constant returned by wait() to indicate // that the wait() was terminated by timeout rather than by a user // signal. static TimeoutArrived @ TIMEOUT_ARRIVED; new TimeoutArrived @=> TIMEOUT_ARRIVED; // ================================================================ // class methods // ChucK 1.2.1.3 exhibits scheduling bugs when passed time values // with non-zero fractional parts. truncate_time() removes the // fractional part to work around the bug. (See set_timeout(t) // for usage.) fun static time truncate_time(time t) { return t - (t % samp); } // ================================================================ // instance variables Object @ _cause; time _timeout_time; // ================================================================ // public instance methods // ================ // wait() blocks until someone calls signal(cause). It then // returns the cause argument. fun Object wait() { this => now; // wait here for call to signal() return _cause; } // ================ // signal(cause) signals the semaphore, allowing it to return from // a call to wait() with the given cause. fun Semaphore signal(Object cause) { cause @=> _cause; // remember the cause of the signal clear_timeouts(); // inhibit pending timeouts this.broadcast(); // unblock the wait() me.yield(); // allow wait()'ing thread to run return this; } // ================ // set_timeout(time) generates a call to signal(TIMEOUT_ARRIVED) in // the future. If <time> has already passed, no timeout is set // and set_timeout() returns null. fun Semaphore set_timeout(dur duration) { return set_timeout(now + duration); } fun Semaphore set_timeout(time t) { if ((truncate_time(t) => _timeout_time) <= now) return null; spork ~ _timeout_proc(t); me.yield(); return this; } // ================ // clear_timeouts() prevents any pending timeouts from generating // a signal(). // // Implementation note: each call to set_timeout() spawns a new // _timeout_proc(), and once spawned, a proc cannot be killed or // interupted. To inhibit subsequent calls to signal(), we set // _timeout_time to an "impossible" value (i.e. a time in the // past) to inhibit the generation of the signals -- see the // implementation of _timeout_proc() to see why this works. fun Semaphore clear_timeouts() { now - 1::second => _timeout_time; return this; } // ================ // wait_for() and wait_until() combine a call to set_timeout() // followed by a wait(): they will block until the desired time // arrives OR until <this>.signal() is called from another thread, // whichever comes first. fun Object wait_for(dur duration) { return wait_until(now + duration); } fun Object wait_until(time t) { if (set_timeout(t) == null) { return TIMEOUT_ARRIVED; // don't wait() if time already passed } else { return this.wait(); } } // ================================================================ // private methods // _timeout_proc() is spawned in its own thread at each call to // set_timeout(). It blocks until the requested time, and if // the timeout is still current (i.e. now == _timeout_time), it // calls <this>.signal(TIMEOUT_ARRIVED) to unblock the wait(). fun void _timeout_proc(time t) { t => now; // wait until the time arrives // Signal the Semaphore only if this timeout is current if (now == _timeout_time) this.signal(TIMEOUT_ARRIVED); } }

1 0

Filter screaming: danger to hearing
by Tomasz Kaye's brain 28 Nov '09

28 Nov '09

Hello all. I know that Kassen already posted to the list about (what seems like) a filter instability problem in certain situations. But after a conversation with him it seemed that I hadn't conveyed the full nature of the problem clearly, so in this post will try to do that. To recap, here's some code from Kijjaz that demonstrates the problem: PulseOsc osc => BPF filter => blackhole; 20000 => filter.freq; 0.5 => filter.Q; for(int i; i < 100; i++) { <<< "osc: ", osc.last(), " filter: ", filter.last() >>>; samp => now; } The value output by the filter keeps rising. I ran into this problem while i had a similar patch connected to dac instead of to a blackhole. I was wearing headphones, but i took the usual precaution of turning my macbook volume to the lowest level above 0 before running the patch. To my alarm, the resulting screaming sound came through my headphones at top volume anyway. It turns out that when set to any of the volume gradations above 0, the screaming happens at effectively full volume on my macbook. So the point of this extra post is to emphasise that (at least for mac users) the filter screaming issue is currently quite dangerous for hearing/speakers, even if you take (imo) normal sensible precautions before running a patch.

3 4

Re: [chuck-users] Newbie envelope glide confusion
by Perry R Cook 26 Nov '09

26 Nov '09

Envelope e => blah; 2.0 => e.target; This has bitten me more than once. I think a great default behavior for an envelope that has nothing chucked into it would be to yield its current value (as if a 1.0 Step function were chucked into it). That way it would act like an envelope "generator" rather than only an envelope "generator and applier." I'll try to remember to lobby to get this folded into a future version of ChucK. PRC

2 1

Static bug
by Hans Aberg 26 Nov '09

26 Nov '09

For some reason, 'chuck' does not instantiate class static constants until there has been an instantiation of the class itself. Hans ---- static.ck ---- class Test { 3 => static int d; fun static void print() { if (d == 0) chout <= "Nope!\n"; else chout <= "Yep.\n"; } } Test.print(); Test test_; Test.print(); ---- run ---- $ chuck static.ck Nope! Yep. ----

5 15

Newbie envelope glide confusion
by Tomasz Kaye's brain 26 Nov '09

26 Nov '09

I expected that the following code would give a tone that would glide to a new frequency each second. But i think I might be misunderstanding the sync property because i'm not getting any audible output from this. Can anyone explain where i'm going wrong? Envelope env => SawOsc osc => dac; 3::ms => env.duration; 0 => osc.sync; // (0) sync frequency to input, while(true){ 1::second => now; Std.rand2f(100,300) => env.target; }

2 2

Re: [chuck-users] chuck neophyte trying to remove clicks via Envelope patch
by Perry R Cook 25 Nov '09

25 Nov '09

Try this simple fix: Std.rand2f(0,1) => float g; // g => s1.gain; // Don't // g => s2.gain; // set the // g => s3.gain; // oscillator gains // g => s4.gain; // individually // which causes clicks g => e.target; // let the envelope do the smoothing

3 2

chuck neophyte trying to remove clicks via Envelope patch
by Ryan Wieghard 25 Nov '09

25 Nov '09

Hello chucKsters, I am trying to write a simple program that reassigns four sine oscillator's pitch and volume at each iteration through a while(true) loop. I decided i didn't want the clicks at the beginning of each note attack, so I thought that I could remove them by just adding an envelope to ramp up to the gain value for each event. After trying different values for the Envelope time and rate, I can't seem to figure out how to remove the clicks. I apologize as this is probably something obvious that I am blind to in my myopic state. My intuition is that if I increased the rate of the envelope the ramp up to 1 would be smoother and then my speakers wouldn't click. However I am unsure how to adjust the rate as I don't know what range it would be in. Sorry for my n00bishness Ryan. SinOsc s1 => Envelope e=> dac; SinOsc s2 => e => dac; SinOsc s3 => e=> dac; SinOsc s4 => e=> dac; //.... while( true ) { .1 => float t =>e.time; //reassign gain Std.rand2f(0,1) => float g; g => s1.gain; g => s2.gain; g => s3.gain; g => s4.gain; //reassign pitch Std.mtof(instrumentSet1[Std.rand2(0,6)]) => s1.freq; Std.mtof(instrumentSet1[Std.rand2(0,6)]) => s2.freq; Std.mtof(instrumentSet1[Std.rand2(0,6)]) => s3.freq; Std.mtof(instrumentSet1[Std.rand2(0,6)]) => s4.freq; //Advance time by 1 samp e.keyOn(); 1000::ms => now; e.keyOff(); } -- "Le savant n’étudie pas la nature parce que cela est utile ; il l’étudie parce qu’il y prend plaisir et il y prend plaisir parce qu’elle est belle." - Henri Poincaré

5 7

Re: [chuck-users] eChucK Update
by Les Hall 24 Nov '09

24 Nov '09

From: Hans Aberg <haberg(a)math.su.se> Date: November 24, 2009 4:43:34 AM EST To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> Subject: Re: [chuck-users] eChucK Update Reply-To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> On 16 Nov 2009, at 11:44, Les Hall wrote: Hi, you may recall that I wrote some time ago about this eChucK project that I dreamed up. ... The second board is extremely simple. It is a little postage-stamp sized breakout board designed to hold one chip plus discreet parts and solid wire interconnect. We can make sound sculptures by connecting these populated boards with the wire and arranging them in 3D. I had 100 boards made for $225 and sold 42 of them so far for $2.50 each, a modest 10% markup due to it being a prototype and all that. I have ordered parts to build two types of sculptures: Chiphenge and Tie Fighter. Do you have any pictures online? And what exactly does this? Is it amplifiers, or can one control them independently on different channels from 'chuck'? Hans Hans, most one-chip circuits can fit on a board, though we usually prefer 4000 series CMOS for Lunettas. Lunettas are typically free-running, though a ChucK interface is certainly a good idea. To read about this project (and see the pics) look here: http://www.electro-music.com/forum/viewtopic.php?t=37233 Enjoy, Les

2 1