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

Chuck and Control Voltage ( CV )
by henrique matias 19 Sep '12

19 Sep '12

Does anyone has experience / references about it ? Am currently controlling my CV stuff using http://www.expert-sleepers.co.uk/silentway.html and outputting via my MOTU card.. Any references/ideas are more than welcome! have a great day ( :

2 5

Re: [chuck-users] STK instrument segmentation fault
by John Ellinger 16 Sep '12

16 Sep '12

Hi Ge, We met at SLEO. I'm using the newest chuck version: 1.3.1.2 (chimera) mac os x : intel : 64-bit. Re: FM sound Yes I recall reading a forum message that FM was an abstract class. Maybe a simple output message could inform users they need to subclass FM. Re: Brass sound I recorded and attached a small example of the Brass sound I get (BrassTest.mp3). To my ears it sounds distorted. (chuck code at end of email). Re: Mandolin ChucK plays correctly and seg faults when finished. This happens consistently on my MacPro. Here's a portion of the crash log. ============================================================= Process: chuck [739] Path: /usr/local/bin/chuck Identifier: chuck Version: ??? (???) Code Type: X86-64 (Native) Parent Process: bash [645] Date/Time: 2012-09-16 16:41:55.256 -0500 OS Version: Mac OS X 10.7.4 (11E53) Report Version: 9 Interval Since Last Report: 103887 sec Crashes Since Last Report: 29 Per-App Crashes Since Last Report: 4 Anonymous UUID: ABA8BB91-CFBC-40A1-BD37-C0F836D908F5 Crashed Thread: 4 com.apple.audio.IOThread.client Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000000000000000d, 0x0000000000000000 VM Regions Near 0: --> __TEXT 0000000100000000-00000001001b1000 [ 1732K] r-x/rwx SM=COW /usr/local/bin/chuck Application Specific Information: objc[739]: garbage collection is OFF Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff85020e42 __semwait_signal + 10 1 libsystem_c.dylib 0x00007fff86869dea nanosleep + 164 2 libsystem_c.dylib 0x00007fff86869bb5 usleep + 53 3 chuck 0x0000000100045fca Chuck_VM::run() + 426 4 chuck 0x00000001000990ac main + 10924 5 chuck 0x00000001000017bd _start + 203 6 chuck 0x00000001000016f1 start + 33 Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff850217e6 kevent + 10 1 libdispatch.dylib 0x00007fff8667f78a _dispatch_mgr_invoke + 923 2 libdispatch.dylib 0x00007fff8667e31a _dispatch_mgr_thread + 54 Thread 2: 0 libsystem_kernel.dylib 0x00007fff85020e42 __semwait_signal + 10 1 libsystem_c.dylib 0x00007fff86869dea nanosleep + 164 2 libsystem_c.dylib 0x00007fff86869bb5 usleep + 53 3 chuck 0x0000000100120dc1 _ZL7kb_loopPv + 113 4 libsystem_c.dylib 0x00007fff868b38bf _pthread_start + 335 5 libsystem_c.dylib 0x00007fff868b6b75 thread_start + 13 Thread 3: 0 libsystem_kernel.dylib 0x00007fff8502047a __accept + 10 1 chuck 0x0000000100040982 ck_accept + 66 2 chuck 0x000000010009b252 otf_cb(void*) + 530 3 libsystem_c.dylib 0x00007fff868b38bf _pthread_start + 335 4 libsystem_c.dylib 0x00007fff868b6b75 thread_start + 13 Thread 4 Crashed:: com.apple.audio.IOThread.client 0 chuck 0x00000001000f2858 Mandolin::~Mandolin() + 56 1 chuck 0x00000001000d8813 Mandolin_dtor + 35 2 chuck 0x0000000100082244 Chuck_Object::~Chuck_Object() + 132 3 chuck 0x0000000100093be1 Chuck_UGen::~Chuck_UGen() + 33 4 chuck 0x00000001000491dd Chuck_VM_Shred::shutdown() + 317 5 chuck 0x0000000100048ee3 Chuck_VM_Shred::~Chuck_VM_Shred() + 35 6 chuck 0x0000000100048e8f Chuck_VM_Shred::~Chuck_VM_Shred() + 15 7 chuck 0x00000001000461be Chuck_VM::compute() + 206 8 chuck 0x0000000100046034 Chuck_VM::run(long) + 84 9 chuck 0x00000001000ac842 Digitalio::cb2(void*, void*, unsigned int, double, unsigned int, void*) + 434 10 chuck 0x00000001000b7316 RtApiCore::callbackEvent(unsigned int, AudioBufferList const*, AudioBufferList const*) + 358 11 chuck 0x00000001000b7197 callbackHandler(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 23 12 com.apple.audio.CoreAudio 0x00007fff82ca59fa HALC_ProxyIOContext::IOWorkLoop() + 2058 13 com.apple.audio.CoreAudio 0x00007fff82ca5151 HALC_ProxyIOContext::IOThreadEntry(void*) + 73 14 com.apple.audio.CoreAudio 0x00007fff82ca500c HALB_IOThread::Entry(void*) + 78 15 libsystem_c.dylib 0x00007fff868b38bf _pthread_start + 335 16 libsystem_c.dylib 0x00007fff868b6b75 thread_start + 13 ============================================================= // Twinkle code with record function Brass inst => dac => Gain g => WvOut w => blackhole; "BrassTest.wav" => w.wavFilename; 0.5 => g.gain; // Melody, Number Of Beats [ [67.0, 1.0], [67.0, 1.0], [74.0, 1.0], [74.0, 1.0], [76.0, 1.0], [76.0, 1.0], [74.0, 2.0], [72.0, 1.5], [72.0, 0.5], [71.0, 1.5], [71.0, 0.5], [69.0, 1.5], [69.0, 0.5], [67.0, 2.0] ] @=> float tune[][]; 0 => int transpose; 120 => int tempo; // Play phrase 1 for( 0 => int i; i < tune.cap(); i++) { Std.mtof( tune[i][0] + transpose ) => inst.freq; inst.noteOn(1.0); 60000::ms * tune[i][1] / tempo => now; inst.noteOff(0); } w.closeFile; 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

1 0

STK instrument segmentation fault
by John Ellinger 16 Sep '12

16 Sep '12

Hi, I'm using chuck version: 1.3.1.2-rc1 (chimera) mac os x 10.7.4 : intel : 64-bit. In preparing a demo of all STK instrument sounds for class each of the instruments instruments played OK at their default settings except these three: Brass, Mandolin, and FM. Here's the code I used ============================== //Twinkle Twinkle // STK instruments /* BandedWG BlowBotl BlowHole Bowed >>> Brass - very distorted Clarinet Flute >>> Mandolin - segmentation fault ModalBar Moog Saxofony Shakers Sitar StifKarp VoicForm >>> FM - segmentation fault BeeThree FMVoices HevyMetl PercFlut Rhodey TubeBell Wurley */ Wurley inst => dac; // Melody, Number Of Beats [ [67.0, 1.0], [67.0, 1.0], [74.0, 1.0], [74.0, 1.0], [76.0, 1.0], [76.0, 1.0], [74.0, 2.0], [72.0, 1.5], [72.0, 0.5], [71.0, 1.5], [71.0, 0.5], [69.0, 1.5], [69.0, 0.5], [67.0, 2.0] ] @=> float tune[][]; 0 => int transpose; 120 => int tempo; // Play phrase 1 for( 0 => int i; i < tune.cap(); i++) { Std.mtof( tune[i][0] + transpose ) => inst.freq; inst.noteOn(1.0); 60000::ms * tune[i][1] / tempo => now; inst.noteOff(0); } 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 2

Re: [chuck-users] 1.3.1 not happy with my jack (64-bit)
by Peter Lutek 15 Sep '12

15 Sep '12

BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }ack.... oops!! so excited about firing up 64-bit chuck, i forgot about the 48k default sampling rate! chuck --srate44100 ....fixes everything. sorry for the noise... cheers! .pltk. On Sun 09/09/12 8:42 PM , plutek plutek(a)infinity.net sent: 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. _______________________________________________ chuck-users mailing list chuck-users(a)lists.cs.princeton.edu [1] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users Links: ------ [1] mailto:chuck-users@lists.cs.princeton.edu

5 8

Fwd: chuck 1.3.1 on Windows 32-bit - possible OSC issue - update re: 1.3.1.1
by Simon Steptoe 15 Sep '12

15 Sep '12

Hi I've tried r.ck and s.ck on 1.3.1.1 and am getting the same issues as before. Either Chuck crashes immediately or soon after adding s.ck... or if things proceed, removing r.ck causes the crash. And it does seem the longer you leave things running, the more certain you'll get a crash when removing r.ck. Ditto for my own patches using OSC... although there have been times when things have run on for a bit without crashing near, or at, the very beginning.. which wasn't the case with 1.3.1.0. If things do get going there are two specific places where things go then awry.. at the first place the sound breaks down into "white noise" for a few seconds but the shreds continue unabated... the second place occurs a few seconds later with a "proper" crash. I only mention the first of these because I've never had happen at that point with previous versions of Chuck. To my eyes at least nothing particular stands out in the code at these points other than there are a lot of shreds active. Also, I've had the "OutOfMemory: while allocating stack" error message a couple of times. I'm not sure if the above is the sort of information that helps... but if there is anything I can do to provide additional info, please let me know. Simon ---------- Forwarded message ---------- From: Simon Steptoe <simonsteptoe(a)yahoo.co.uk> Date: 11 September 2012 09:45 Subject: chuck 1.3.1 on Windows 32-bit - possible OSC issue To: chuck-users(a)lists.cs.princeton.edu 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

3 4

Fwd: chuck-users Digest, Vol 86, Issue 19
by Simon Steptoe 14 Sep '12

14 Sep '12

Good evening Ge... I've tried r.ck and s.ck out on 1.3.1.2-rc1.. and.... I've yet to make it crash!! Also my own patches using OSC are performing as before (i.e. on 1.3.0.2) without a hitch. So, as least from my perspective, the latest fixes seem to have done the job. Thanks. Simon > ---------- Forwarded message ---------- > From: Ge Wang <ge(a)ccrma.Stanford.EDU> > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Cc: > Date: Fri, 14 Sep 2012 06:26:54 -0700 (PDT) > Subject: Re: [chuck-users] Fwd: chuck 1.3.1 on Windows 32-bit - possible > OSC issue - update re: 1.3.1.1 > Hi Simon! > > I've tried r.ck and s.ck on 1.3.1.1 and am getting the same issues as >>> before. Either Chuck crashes immediately or soon after adding s.ck... or if >>> things proceed, removing r.ck causes the crash. And it does seem the >>> longer you leave things running, the more certain you'll get a crash when >>> removing r.ck. >>> >> >> This is super helpful - we'll look into it starting on windows 32-bit ( >> s.ck and r.ck seems OK on OS X). Thank you! >> > > Alrighty, we've found at least one issue that was definitely a potential > culprit on 32-bit (all os) and only since the 64-bit release. basically, > float and complex local variables where not being properly popped from the > operand stack correctly. > > I uploaded a build (1.3.1.2-rc1) for you as well as for Michael and anyone > else who may want to test particular issues: > > http://chuck.stanford.edu/**stuff/chuck-1.3.1.2-rc1.zip<http://chuck.stanford.edu/stuff/chuck-1.3.1.2-rc1.zip> > > It includes a win32 build and an osx64 build, as well as source for all > supported platforms. > > If you'd like, please give it a spin! > > Thanks! > > Ge! >

1 0

1.3.1.0 (chimera) [part 1]: 64-bit chuck
by Ge Wang 14 Sep '12

14 Sep '12

Dear all, chuck-1.3.1.0 (chimera) is available: http://chuck.cs.princeton.edu/ http://chuck.stanford.edu/ ChucK is, at last, 64-bit compatible. Lack of native 64-bit support has been a long standing issue with ChucK, and many people in our community over the last few years have contributed to making this happen. They include Kassen for his ever helpful voice of reason, Paul Brossier (who did a 64-bit port of ChucK 1.2.0.8 to ubuntu, a port that this release is largely based upon), Stephen Sinclair, who also provided a comprehensive and well-executed 64-bit port, and more recently Robin Haberkorn, who has jumped into the ChucKian development fire, as well as Michael Wilson -- your initiative and insights have definitely helped to make this happen. There have been many helpful discussions on chuck-users and chuck-dev, at CCRMA, as well as much encouragement and support from friends and colleagues like Fernando Lopez-Lezcano. ... Of course, had we/I architected the VM instructions to not make integer, float, and pointer size assumptions in the first place in 2006 with ChucK 1.2, it would have made things quite a bit easier for everyone. Yeah... Oops. This is the very first release of ChucK that natively support 64-bit as well as 32-bit. There are a few additional features (and likely a few new, uh, "features"). I imagine a few hot-fixin' rapid incremental releases might be needed. We have tried to test this thoroughly, in particular on Linux and Mac OS X, and less so on windows. To be totally honest, we have not been able to even test compilation for 64-bit on windows - if someone out there with access to 64-bit windows (XP or Windows7) who can give this a shot, that would be much appreciated! In general, users of all supported systems, please let us know if/how well this works for you! Part 2 -- on the way! Not unlike the final installment of the Harry Potter movies, or perhaps the video game ->Final<- Fantasy XIII (there is a FF XIII-2 and what is effectively FF XIII-3 was just announced), this 1.3.1.0 release will take place in multiple parts, mostly because Spencer is traveling to ICMC in Ljubljana, Slovenia, where he will present our paper on Chugins, Chugens, and Chubgraphs. Also, there is a little bit more work to do for 64-bit miniAudicle, so that's going to come in CK 1.3.1.0, part 2, and probably from Slovenia (it seems only fitting to release ChucK from the international computer music conference). Also, our dear friend Graham Coleman has asked about a chuck-1.3 version of (gasp) Audicle, so there might be a 1.3.1.0, part 2, b. As usual, please see the release notes at the end of this email. Thanks and Happy ChucKin, UpChucKin, Chugin'! gg!! ChucK on!! Best, Spencer + Ge, on behalf of entire chuck team --- 1.3.1.0 - (added) 64-bit support for all platforms (OS X, Linux, Windows) many thanks to Paul Brossier, Stephen Sinclair, Robin Haberkorn, Michael Wilson, Kassen, and Fernando Lopez-Lezcano, and all of chuck-users! - (added) Math.random(), random2(), randomf(), random2f(), srandom(), and Math.RANDOM_MAX; NOTE: randomf() returns range 0.0 to 1.0 these use the much better random() stdlib functions the existing Std.rand*() and Std.srand() is still be available for compatibility (these to be deprecated in the future; please start using Math.random*()) * (NOTE: on windows, Math.random() still uses the same generator as Std.rand() -- we hope to improve this in a future version!) * (NOTE: also see removed below) - (added) chuck --version | chuck --about now print architecture (32-bit or 64-bit) - (added) Machine.intsize() will return int width in bits (e.g., 32 or 64) - (added) examples/array/array_mmixed.ck to verify mixed-index fix (see below), based on Robin Haberkorn's test code - (fixed) multi-dimensional arrays now correctly support mix-typed indices (e.g., strings & ints) (thanks Robin Haberkorn) - (fixed) constants in Math library now cleaner, they include: * Math.PI * Math.TWO_PI * Math.e or Math.E * Math.i or Math.I or Math.j or Math.J // as 'complex' type * Math.INFINITY * Math.RANDOM_MAX * Math.INT_MAX // currently, differs on 32-bit and 64-bit * Math.FLOAT_MAX * Math.FLOAT_MIN_MAG // minimum positive float value - (fixed) Chubgraph.gain(), .last(), and .op() - (fixed) error message printing system for variable arguments - (fixed) StifKarp.sustain now works properly - (fixed) all examples now use Math.random*() instead of Std.rand*() - (removed) Math.rand*() removed --> please use Math.random*(); (see 'added' above; Std.rand*() still there, but to be deprecated; please use Math.random*() moving forward)

6 11

New error message appears in 64 bit
by John Ellinger 14 Sep '12

14 Sep '12

Hi, I'm using the latest ChucK 1.3.1.1 64bit on Mac 10.7.4. I've been getting this error message whenever running ChucK in the Terminal: [chuck]: cannot bind to tcp port 8888… ChucK programs continue to run fine, it's the first time I've seen this error message. I've been compiling the ChucK svn source code in Xcode for several months. The newest version compiles cleanly with no errors or warnings on Xcode 4.3.3. I've modified the Xcode project settings specifically to x86_64 and OS 10.7. This error string appears only once in chuck_main.cpp line 946. #ifndef __DISABLE_OTF_SERVER__ // log EM_log( CK_LOG_SYSTEM, "starting listener on port: %d...", g_port ); // start tcp server g_sock = ck_tcp_create( 1 ); if( !g_sock || !ck_bind( g_sock, g_port ) || !ck_listen( g_sock, 10 ) ) { >>>> fprintf( stderr, "[chuck]: cannot bind to tcp port %li...\n", g_port ); ck_close( g_sock ); g_sock = NULL; } else { ... } #endif // __DISABLE_OTF_SERVER__ In chuck_def.h "#define __DISABLE_OTF_SERVER__" is only defined if __CHIP_MODE__ is defined. I could not find "#define __CHIP_MODE__" anywhere in the 1.3.1.1 branch. If __CHIP_MODE__ is not defined, __DISABLE_OTF_SERVER__ is not defined, hence the error. 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

Chuck can't find my chugins ?
by Casper Schipper 14 Sep '12

14 Sep '12

Hi, I seem to have a problem finding my chugins with mini-audicle (version 0.2.2a (gidora)). When I try to load a compiled Chugin (located in /usr/lib/chuck I simply get : [Untitled]:line(1): undefined type 'Bitcrusher'... [Untitled]:line(1): ... in declaration ... any idea what is going on ? Should I compile them for 64 bits now for example ? Cheers, Casper

2 1

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