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

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

negative zero
by Robert Poor 01 Mar '09

01 Mar '09

I'm troubled by ChucK's handling of negative zero. A variable set to -0.0 is indistinguishable from a variable set to 0.0, except in printing. This is not a problem in everyday practice, but it seems likely that it will cause trouble when you pass to an external program. [Why would you set a variable to -0.0 in the first place? Try this: (-3.0 % 1.0) => float bar;] Comments? ==================== 0.0 => float foo; -0.0 => float bar; // even though foo and bar print differently... <<< "foo = ", foo, " bar = ", bar >>>; // in ChucK's eyes, they are both considered to be zero... <<< "sgn(foo) = ", Std.sgn(foo), " sgn(bar) = ", Std.sgn(bar) >>>; // and they are equal... if (foo == bar) { <<< "equal" >>>; } ==================== produces ==================== % chuck test.ck foo = 0.000000 bar = -0.000000 sgn(foo) = 0.000000 sgn(bar) = 0.000000 "equal" : (string) ====================

3 4