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

some bugs on windows ChucK
by Graham Coleman 14 Sep '12

14 Sep '12

Greetings, First, congratulations to chuck team and all responsible for the recent releases. I found a few bugs, these were tested in the latest ChucK and miniAudicle builds (win32) on 64-bit Windows 7 machines. 1. Machine.add doesn't seem to support drive specifications in paths. ( test1.ck) <<< Machine.add( "C:/Users/Public/test2.ck" ) >>>; //doesn't work <<< Machine.add( "/Users/Public/test2.ck" ) >>>; //works 2. A crashing bug when dealing with string non-literals. (test6.ck) I was unable to reproduce it outside of an OSC context, I don't know if it affects non-Windows systems. Basically, I was capturing string arguments from received OSC messages, and I found that one usage worked fine: <<< tsEvent.getString() >>>; //this should work but that trying to store it into a string object was crashing: tsEvent.getString() => string str2; //this should crash <<< str2 >>>; regards, Graham

3 5

Why does the gain increase each time through the loop
by John Ellinger 13 Sep '12

13 Sep '12

Hi all, After attending the SLEO conference last spring I was inspired to start a laptop group at Carleton College. I've run into a problem I don't understand. I'm using chuck version: 1.3.1.1 (chimera) mac os x : intel : 64-bit I've interfaced a 4x4 numeric touchpad to an Arduino controller that sends MIDI to Chuck. The MIDI reception works fine. I mapped keypad number 1 to a kick drum sample which works fine. The problem is every time I press keypad 1 the gain increases. This skeleton code illustrates the issue. ============================ // gain test SndBuf bufKick => blackhole; // change to your path "/Users/je/Documents/ArduinoXCode/midikeypad_git/chuck_pad/data/kick.wav" => bufKick.read; // set the kick gain 0.5 => bufKick.gain; // get the kick duration bufKick.length() => dur bufKickDur; function void playKick() { 0 => bufKick.pos; bufKick => dac; bufKickDur => now; } // infinite time-loop while( true ) { playKick(); 1::second => now; } =============================== I've tried things like this fun void playKick() { 0 => bufKick.pos; bufKick => Gain g => dac; g.gain() => float oldgain; bufKickDur => now; oldgain => g.gain; } and this fun void playKick() { 0 => bufKick.pos; bufKick => dac; bufKick.gain() => float oldgain; bufKickDur => now; oldgain => bufKick.gain; } but the gain still increases on every button press. How can I keep the gain at a constant level? It was a pleasure to meet and talk with Ge and Spencer at SLEO. John John Ellinger email: info(a)mibac.com MiBAC Music Software 1019 College St. Music Instruction By A Computer Northfield MN 55057 http://www.mibac.com

2 1

bus error in 1.3.0.2
by David Loberg Code 13 Sep '12

13 Sep '12

In v.1.3.0.2, I am getting bus errors with server/client stuff (Clix, Crystalis, etc.) Any thoughts? > line 3: 281 Bus error: 10 chuck pieces/Clix/server-multi_auto.ck I tried v.1.3.1.0 and I got even more errors. I reverted back to 1.3.1.4-beta and things were functioning well again. thanks, david David Loberg Code School of Music Western Michigan University 1903 W Michigan Ave Kalamazoo, MI 49008-5434 code(a)wmich.edu

2 2

1.3.1.1 (chimera) released (critical fix)
by Ge Wang 13 Sep '12

13 Sep '12

Greetings all! chuck-1.3.1.1 (chimera) is available: http://chuck.cs.princeton.edu/ http://chuck.stanford.edu/ This version fixes a critical issue that was introduced in 1.3.0.0 where member function calls in loop conditionals, paired with having an Object reference in the body, can cause a crash. This is quite likely the source of the OSC-related crashes that quite a few people have reported recently. It actually wasn't an issue with OSC (though we did tighten a few things there too), but rather the common usage: // e is an Event in this example while( e.nextMsg() ) { /* do stuff... */ } So, this should now be fixed (we think)! This issue was a rather serious one (the code above is commonly found when working with OSC, MIDI, HID, and any time a member function is invoked in loop conditional). We highly recommend updating to the latest as soon as convenient! Thanks to everyone who reported issues and helped to track things down! If you'd like, please do give 1.3.1.1 a spin, and let us if you run into additional issues -- we'll do our best to get things fixed as soon as we can! Thank you and ChucK on! Best wishes, Spencer, Ge + on behalf of chuck team! 1.3.1.1 --- - (fixed) critical bug since 1.3 where member function calls in loop conditionals caused crashes when the loop body contained local Object's to be released; this directly affects using OSC, MIDI, HID, which commonly employ syntax like: 'while( e.nextMesg() ) { ... }'; -- this is most likely the cause of the OSC-related issues we've been seeing (thanks to Graham Coleman for tracking down and narrowingthe issue!) - (fixed) strengthened synchronization in OSC between internal listener thread and chuck VM code - (fixed) memory bug in OscRecv deallocation - (fixed) Machine.add( ... ) on windows now supports both '\\' and '/' in aboslute paths (previously only '\\'). (thanks to Graham Coleman for finding this!)

1 0

toplap page
by Kassen 11 Sep '12

11 Sep '12

Hey all! http://toplap.org/ That is the new and far more exciting TOPLAP page. It's colourful, more friendly, and has no ChucK on it. Does anyone have a nice (recent-ish) video or write-up about livecoding with ChucK that they'd like to have there? I'd say "I could post that", but that would be a lie. It'd be more like "I should be able to post that" because I don't know how it all works, yet :-) Anyway, it needs some of our stuff chucked into it. Yours, Kas.

1 0

chuck 1.3.1 on Windows 32-bit - possible OSC issue
by Simon Steptoe 11 Sep '12

11 Sep '12

Some of my existing patches are causing Chuck 1.3.1 to lock-up and crash. I think I've traced it back to a possible OSC issue as the example files s.ck and r.ck seem to cause the same problem... which would make sense in that my affected patches are also using OSC events. If the patch gets going at all, removing the shred(s) also causes a crash. OSC_send.ck and OSC_recv.ck however seem to work fine. On my own patches I can sometimes catch the error message; "OutOfMemory: while allocating stack"... increasing buffer size and/or decreasing sample rate seem to alleviate the problem somewhat in that things keep running a few seconds longer, but eventually the result is the same. However, I guess this might not be the same issue as with s.ck and r.ck. Running Chuck with --silent doesn't resolve things either. My machine is Windows 7, 32-bit... to be fair it is a bit on the old side (Pentium 4)... but it's coped fine with previous versions of Chuck and miniAudicle.... and I can't replicate the issue with Chuck 1.3.0.2. Many thanks. Simon

2 1

1.3.1 not happy with my jack (64-bit)
by plutek 09 Sep '12

09 Sep '12

greetings! i just compiled 1.3.1 on a 64-bit linux system. compilation for jack went fine, and chuck runs without error messages. however.... no jack client is created. (so, of course, i hear nothing) shreds don't actually get started. (i.e. chuck ^ shows NOTHING) when i stop chuck, it says: RtApiJack::closeStream(): no open stream to close! if i run with --silent, incoming shreds DO show up. my jack is working fine with other applications. any clues? what shall i send to help figure this out? thanks much... cheers! .pltk.

1 0

#chucktweets
by Thomas McColgan 08 Sep '12

08 Sep '12

Hi all, I was just playing around with chuck and I thought it would be fun to have a hashtag of chucktweets on twitter in the spirit of #sctweets that the supercollider guys have, ie self contained compositions that fit into 140 chars. I went ahead and posted a very simple one of my own: https://twitter.com/phreeza/status/242609758404747264 Looking forward to seeing what you guys can come up with. Cheers, Thomas

4 3

miniAudicle-0.2.2 (gidora) released
by Spencer Salazar 07 Sep '12

07 Sep '12

Howdy from Ljubljana, miniAudicle-0.2.2 has been released: http://audicle.cs.princeton.edu/mini/ The primary purpose of this release is to provide interoperability with the shiny new 64-bit chuck-1.3.1.0, for which minor cleanup of miniAudicle's internal workings was necessary. Also note that the Windows executable is still 32-bit, as we lack the appropriate resources to build/test on 64-bit Windows. Please let us know about any problems, bugs, feature requests, etc. Thanks, Spencer, Ge, + chuck team --- 0.2.2 - (added) chuck-1.3.1.0 - (fixed) 64-bit support

1 0

nable to find audio input device with requested channel count
by Jonas Gruska 07 Sep '12

07 Sep '12

Dear fellow Chuck users, I am now working on a system with no ADC, thus no input channels. But, for some reason, Chuck wants to use those, no matter the program. To quote: [chuck]: unable to find audio input device with requested channel count (2) [chuck]: cannot initialize audio device (try using --silent/-s) When I try adding --in0 it doesn't accept it as valid option. Is there a way how to deal with this? Regards, Jonas

2 1