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

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

problem with osc over network
by Bozelos Dimitris 14 Mar '09

14 Mar '09

Hi all, I'm working on a group project and I chose to use chuck not having "chucked" at all before. So we need to send / receive osc messages over the network with the other groups members and i've run into some problems, I don't receive the messages other people send me. I can send messages with chuck succesfully and receive successfully with supercollider. So there is no problem with the network / firewall. Here is my code for receiving: OscRecv recv; 6449 => recv.port; recv.listen(); recv.event( "/address, f" ) @=> OscEvent @ oeFloat; float k; while( true ) { oeFloat => now; while( oeFloat.nextMsg() ) { oeFloat.getFloat() => k; <<<k>>>; } 1000::ms => now; } Is there anything that I miss? This code works fine at localhost (from a chuck shred to another). The other people are sending messages with Max/MSP and SuperCollider, can this cause problems? Can there be a mismatch of the type of the incoming message with what is expected? Although I was sure while testing that the message from Max/MSP was sent as a float, can this be a problem somehow? Any thoughts would be appreciated, Dimitris ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

1 0

cross-referenced classes?
by Robert Poor 13 Mar '09

13 Mar '09

Assume I have the following: ===== file: scratch.ck ===== public class Scratch { Sniff _sniff; } ===== EOF ===== ===== file: sniff.ck ===== public class Sniff { Scratch @ _scratch; } ===== EOF ===== How does one compile cross-referenced classes? Neither "chuck scratch.ck sniff.ck" nor "chuck sniff.ck scratch.ck" bring joy. (There's a similar question for any class that has a reference to itself as a member, such as a linked list. But I'll save that question for the next time I need to flaunt my ignorance.) - Rob

4 9

iterating over an associative array?
by Robert Poor 12 Mar '09

12 Mar '09

How does one iterate over an associative array in ChucK?

3 2

Bad return signature in pre-constructor leads to null instance
by Robert Poor 12 Mar '09

12 Mar '09

Got a bug for the team. Don't ask me how long it took me to track it down. Consider this code and the effect of running it: ============== public class Foo { bad_pre_constructor(); fun float bad_pre_constructor() { <<< "bad_pre_constructor, this =", this >>>; } } Foo bad_foo; <<< bad_foo =", bad_foo>>> ============== % chuck foo.ck bad_pre_constructor, this = 0x634720 bad_foo = 0x0 ============== Note that the instance of bad_foo is null. Now consider this code: ============== public class Foo { good_pre_constructor(); fun void good_pre_constructor() { <<< "good_pre_constructor, this =", this >>>; } } Foo good_foo; <<< good_foo =", good_foo>>> ============== % chuck foo.ck good_pre_constructor, this = 0x634720 good_foo = 0x634720 ============== Note that the instance of good_foo is a reasonable non-null value. Did you spot the difference? "bad_pre_constructor" is declared (improperly) to return a float, but it doesn't, and an instantiation of Foo silently returns a null. "good_pre_constructor" is properly declared with a void return, and an instantiation of Foo returns a good value. So yes, this was operator error -- it's an error not to return a value when you claim you're going to. But ChucK fails silently, at least until you get hit with a NullPointerException some time later in the execution. This is not friendly behavior. - Rob P.S.: Uh, is this the right forum for reporting bugs like this?

3 5

benchmarking UGens
by Atte André Jensen 12 Mar '09

12 Mar '09

Hi We all know that chuck is not the fastest audio software out there. But I guess like me you've all found ways to work around that. I often found myself wondering "how much can I save by disconnecting this UGen" or "exactly how expensive is another NRev". For this purpose I started to do some benchmarking in the form of a bunch of .ck files and a bash script. My initial results are here: http://atte.dk/chuck/results.txt The first line is "chuck --loop", so the wm alone. "nb" is the number of files, "cpu" is the cpu usage as reported by htop on my laptop (2Ghz Intel dualcore), and "cpu normalized" is cpu-usage (simple multiplication) at nb=100. Of course this doesn't make sense without seeing the .ck files, so I've put them here: http://atte.dk/chuck/performance_tests.tgz I'm quite aware of that this approach is very un-scientific, so any input on how to improve it is more than welcome. Esp. I'm wondering how 10 * PRCRev = 7% and 50 * PRCRev = 46% (should have been 35%). I'm gonna continue my tests, but you're all welcome to supply files for testing. Maybe this should all end up on the wiki? NB: This is in no way a critique of the developers. Sure I would love to see a faster chuck, but we still love it and use it. -- Atte http://atte.dk http://modlys.dk

6 30

popBack() bug?
by mike clemow 02 Mar '09

02 Mar '09

Hey all, I'm pretty sure that popBack() is broken: class Stack { string stack[0]; fun void push( string s ) { stack << s; } fun string pop() { stack[stack.size()-1] => string s; //stack.popBack(); // comment this out and it works... return s; } } Stack stack; stack.push( "five" ); stack.push( "six" ); <<< stack.pop() >>>; <<< stack.stack[0] >>>; --- This will crash with this error: chuck_oo.cpp:114: failed assertion `m_ref_count > 0' Abort trap Anyone else run into this? -Mike -- http://michaelclemow.com http://semiotech.org

1 0