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

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

Chout flush
by Hans Aberg 24 Nov '09

24 Nov '09

Is there a way to flush chout (and cherr) other than sending "\n"? Hans

3 5

eChucK Update
by Les Hall 24 Nov '09

24 Nov '09

Hi, you may recall that I wrote some time ago about this eChucK project that I dreamed up. It had some fits and stumbles at first, but now the concept is evolving into actual products. The first board didn't really work out for various reasons so I basically took a $130 hit and cut my losses, giving three boards out for free to people who might make use of them. Oh well, you win some you lose some. 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. Next on the horizon is a Karplus Strong board implemented as an analog circuit. Just yesterday I completed the prototype in breadboard form and I cannot express how satisfying it was to listen to guitar and percussion sounds, and it even does a pretty good motor cycle / chain saw sound, heh. I spent most of Sunday afternoon broadcasting test audio of it on my internet radio port to friends, who really enjoyed the variety of sounds that it makes. Next up: order parts then complete the board design. Finally, I have a Boolean Sequencer board, a song timer board, and a clock / battery board planned to round out the selection of ChucK-inspired eChucK DIY products. It is a lot of fun to put my engineering knowledge to good use for a change. Oh, one more thing. There is now an eChucK forum sitting right next to the ChucK forum on www.electro-music.com, so stop by and have a read if you like. That's all for now. Keep on ChucKin'. Les

2 1