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

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

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

wavetable synthesis
by Michael Heuer 06 Sep '12

06 Sep '12

Hello, I found this collection of 600-sample one cycle waveforms recently http://www.adventurekid.se/AKRT/ If I wanted to use these for "wavetable synthesis", is it just a matter of wrapping a looping SndBuf or LiSa with ADSR and tweaking the freq? What if I wanted to do something like the Shruthi1 hardware http://mutable-instruments.net/shruthi1/manual or the Animoog app http://www.moogmusic.com/products/apps/animoog-0 where a bunch of waveforms are combined into a single wavetable, e.g. the Shruthi1 doc "All these waveforms are wavetables, comprising 16 single-cycle waveforms. The parameter scans the wavetable, smoothly interpolating between each waveform. Some of these tables are 'transwaves': the single cycle waveforms were extracted from different 'stages' of a sample, and you can somehow recreate the original sample by using an envelope that will sweep the parameter from 0 to 127." Sorry if this question is Electronic Music 101. michael

2 4

problems with chubgraphs
by Robin Haberkorn 03 Sep '12

03 Sep '12

Sorry to bother you again, but I'm experiencing difficulties using the new Chubgraph feature. Using v1.3.0.2 of course. class TestChubgraph extends Chubgraph { SinOsc o => dac; 400 => o.freq; } TestChubgraph c; 10::second => now; This code does the sine wave sound but it should be silent since "c" is not connected to dac. Reading the Chubgraph example, I thought that the dac in the Chubgraph class is local to the object instance - as a way to connect to the UGen's output. Also what's strange is that the number of channels reported for dac in the class is the same as the number of output channels I've requested for ChucK. Did I miss something or is it a bug? Also thinking about Chugens, could someone comment on the performance aspect of using them for audio-rate processing (in comparison to a traditional 1::samp loop, e.g. in a Chubgraph)? Thanks in advance, Robin

4 9

me.source* always empty with chuck add
by Todd Willey 03 Sep '12

03 Sep '12

The examples/otf_01.ck file recommends running `chuck --loop` in one terminal, and `chuck + otf_01.ck` in another. The looping vm bombs out at: me.sourceDir() + "/data/kick.wav" => buf.read; with: [chuck](via SndBuf): cannot stat file '/data/kick.wav'... After adding some debugging statements, it looks like me.sourceDir returns the empty string, as does me.sourcePath. If there is a more appropriate place to report/discuss these things, please let me know. -todd[1]

3 4

one sample block size vs demand rate
by ronni montoya 31 Aug '12

31 Aug '12

Hi guys, before we were talking about the differences between sc3 and chuck , and people said that in sc3 you cannot do one sample manipulation but i just discovered that sc3 has a group of ugens called "demand ugens" that allows to do one sample manipulation(one sample block). Do you guys know about this? What do you think about the posibilities of one sample block size in chuck vs demant rate posibilities in sc3? Are they both equivalent? or can you make things that you cannot do with the other? thanks in advance. R.

3 2

1.3.0.0 (chimera) unleashed!
by Spencer Salazar 29 Aug '12

29 Aug '12

Dear all, chuck-1.3.0.0 (chimera) is available: http://chuck.cs.princeton.edu/ http://chuck.stanford.edu/ This release incorporates ChuGins, a new way to extend ChucK. ChuGins are a continual work in progress, and we encourage feedback in anticipation of rapid updates, tweaks, and fixes. Chugens and Chubgraphs provide additional mechanisms for extending ChucK's built-in audio capabilities. Furthermore, this release variety of smaller fixes and additions. To start developing ChuGins, please see several examples here, in addition to the chuginate utility, which generates the skeleton framework for a new ChuGin. https://github.com/spencersalazar/chugins and: https://ccrma.stanford.edu/~spencer/publications/CCC2012.pdf (Please see the release notes at the end of this email.) Many many thanks once again to Kassen, Casper Schipper, Jorge Herrera, Hongchan Choi, and everyone on chuck-users, as well as PLOrk, SLOrk, the Food Services Division at Smule, Fernando Lopez-Lezcano, Carr Wilkerson, Chris Chafe, and the rest of the chuck community for making this release happen! Thanks and Happy ChucKing, UpChucKing! Best, Ge + Spencer, on behalf of entire chuck team --- 1.3.0.0 - (added) Chugins: dynamically loaded compiled classes/ugens see http://chuck.stanford.edu/extend/ for examples. - (added) new command line options --chugin-load:{auto|off} disable/enable chugin loading -gFILE/--chugin:FILE load chugin at FILE -GPATH/--chugin-path:PATH load all chugins in directory PATH --dac:NAME use dac with name matching NAME --adc:NAME use adc with name matching NAME - (added) Chubgraphs: create ugens by compositing existing UGens see examples/extend/chubgraph.ck - (added) ChuGens: create ugen by implementing audio-rate processing in ChucK see examples/extend/chugen.ck - (added) new ugens: - WvOut2: stereo uncompressed audio file output - SndBuf2: stereo uncompressed audio file input - (added) new functions: - me.sourcePath() returns file path of source file corresponding to this shred - me.sourceDir() returns directory of source file corresponding to this shred - MidiIn.open(string name) open MIDI input matching name - MidiOut.open(string name) open MIDI output matching name - Hid.open(string name) open HID matching name - (added) experimental OS X multitouch HID - (fixed) real-time audio on Mac OS X 10.7 (Lion), 10.8 (Mountain Lion) - (fixed) IO.newline() now flushes "chout" - (fixed) "chout" and "cherr" now invoke member functions correctly - (fixed) no for statement conditional handled correctly - (fixed) STK WvOut correctly handles case when file open fails - (fixed) << operator for arrays now correctly references counts - (fixed) crashing bug when receiving external events at a high-rate ("the OSC bug") - (fixed) scope closing correctly dereferences local objects - (fixed) crash when exiting shreds with connected ugens - (fixed) deallocation of "empty" Shred object no longer crashes - (fixed) crash when HID events are sent to an exited shred - (fixed) destructors for built-in objects are executed

8 16

severe ChucK v1.3.0.0 bug
by Robin Haberkorn 29 Aug '12

29 Aug '12

system: rhaberkorn@nb005-lx001:~$ uname -a Linux nb005-lx001 2.6.32-42-generic #95-Ubuntu SMP Wed Jul 25 15:56:09 UTC 2012 x86_64 GNU/Linux rhaberkorn@nb005-lx001:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04.4 LTS" I'm using a ChucK build with my own modifications (-m32 and some that are Jack-related). test case: fun void foo(string s) { //<<< s >>>; } while (true) { //<<< 1 >>>; "bar" => foo; //<<< 2 >>>; } result: rhaberkorn@nb005-lx001:~$ chuck --srate:44100 bug.ck chuck: chuck_oo.cpp:125: void Chuck_VM_Object::release(): Assertion `m_ref_count > 0' failed. Aborted uncommenting the debug prints: rhaberkorn@nb005-lx001:~$ chuck-1.3.0.0/src/chuck --srate:44100 bug.ck 1 :(int) "bar" : (string) 2 :(int) 1 :(int) "bar" : (string) Segmentation fault (core dumped) rhaberkorn@nb005-lx001:~$ gdb ./chuck-1.3.0.0/src/chuck ./core GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/rhaberkorn/chuck-1.3.0.0/src/chuck...done. [New Thread 1192] [New Thread 1199] [New Thread 1198] [New Thread 1193] [New Thread 1200] warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib32/libasound.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libasound.so.2 Reading symbols from /usr/local/lib32/libjack.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib32/libjack.so.0 Reading symbols from /usr/lib32/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libstdc++.so.6 Reading symbols from /lib32/libdl.so.2...Reading symbols from /usr/lib/debug/lib32/libdl-2.11.1.so...done. done. Loaded symbols for /lib32/libdl.so.2 Reading symbols from /lib32/libpthread.so.0...Reading symbols from /usr/lib/debug/lib32/libpthread-2.11.1.so...done. done. Loaded symbols for /lib32/libpthread.so.0 Reading symbols from /usr/lib32/libFLAC.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libFLAC.so.8 Reading symbols from /usr/lib32/libogg.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libogg.so.0 Reading symbols from /usr/lib32/libvorbis.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libvorbis.so.0 Reading symbols from /usr/lib32/libvorbisenc.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libvorbisenc.so.2 Reading symbols from /lib32/libm.so.6...Reading symbols from /usr/lib/debug/lib32/libm-2.11.1.so...done. done. Loaded symbols for /lib32/libm.so.6 Reading symbols from /usr/lib32/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libgcc_s.so.1 Reading symbols from /lib32/libc.so.6...Reading symbols from /usr/lib/debug/lib32/libc-2.11.1.so...done. done. Loaded symbols for /lib32/libc.so.6 Reading symbols from /lib32/librt.so.1...Reading symbols from /usr/lib/debug/lib32/librt-2.11.1.so...done. done. Loaded symbols for /lib32/librt.so.1 Reading symbols from /usr/lib32/libcelt0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libcelt0.so.0 Reading symbols from /lib/ld-linux.so.2... warning: the debug information found in "/lib/ld-2.11.1.so" does not match "/lib/ld-linux.so.2" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//lib/ld-2.11.1.so" does not match "/lib/ld-linux.so.2" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/lib/ld-2.11.1.so" does not match "/lib/ld-linux.so.2" (CRC mismatch). (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Core was generated by `chuck-1.3.0.0/src/chuck --srate:44100 bug.ck'. Program terminated with signal 11, Segmentation fault. #0 0x080ab3c8 in Chuck_VM_Alloc::free_object (this=0x8491028, obj=0x85d1108) at chuck_oo.cpp:259 259 delete obj; (gdb) bt #0 0x080ab3c8 in Chuck_VM_Alloc::free_object (this=0x8491028, obj=0x85d1108) at chuck_oo.cpp:259 #1 0x080ab1f4 in Chuck_VM_Object::release (this=0x85d1108) at chuck_oo.cpp:148 #2 0x08069abb in Chuck_Instr_Release_Object2::execute (this=0x85d1c40, vm=0x8491780, shred=0x85d1f58) at chuck_instr.cpp:3232 #3 0x0805ba3f in Chuck_VM_Shred::run (this=0x85d1f58, vm=0x8491780) at chuck_vm.cpp:1677 #4 0x08059492 in Chuck_VM::compute (this=0x8491780) at chuck_vm.cpp:655 #5 0x080593d9 in Chuck_VM::run (this=0x8491780) at chuck_vm.cpp:602 #6 0x080c952a in main (argc=3, argv=0xffaeda04) at chuck_main.cpp:969 (gdb)

4 8

Re: [chuck-users] WvOut: writes soundfile, but always silent
by Joel Matthys 29 Aug '12

29 Aug '12

Same here. I can't get WvOut to work in chimera on Linux. Simple example which works on 1.2.1.3: Noise n => dac => WvOut rec => blackhole; 0.25 => n.gain; "rec_test" => rec.wavFilename; 2::second => now; rec.closeFile(); but with 1.3.0.0 I have to abort with ctrl+c and get: chuck: chuck_oo.cpp:125: void Chuck_VM_Object::release(): Assertion `m_ref_count > 0' failed. and silent audio file. No success with WvOut2 either. Different issue, but I also get this often when chuck is exiting: terminate called after throwing an instance of 'RtError' Aborted (core dumped) (the chirp.ck example in the basic folder always gives this error) Joel On 08/26/2012 05:10 PM, chuck-users-request(a)lists.cs.princeton.edu wrote: > Thanks Joel. > > Unfortunately, sorry, that doesn't help, on either example. > > I do now get a freeze at > fCoreAudioDriverUID AppleHDAEngineInput:8,0,1,0:1 > > if I then press ctrl+c I get: > ^C[chuck]: cleaning up... > > which never exits. > > Does anyone have any minimal code example of a single file which > creates a sound with ChucK, and writes out a sound file from it, that > definitely works on their system for chimera? Perhaps I'm missing > another parenthesis, or some other function call. The examples from > the help tutorial, examples folder rec.ck file, mailing list etc might > need updating? > > best, > Nick

3 4

noob: machine.add but can't find function
by George Locke 26 Aug '12

26 Aug '12

Hi, I've got a chuck file called rand.ck that defines functions, and another that machine.add's rand.ck, but can't find the functions rand.ck " fun float rand_norm() { // Marsaglia polar method, wastes the second ind var float s, x, y; 0 => s; while (s == 0 || s >= 1) { Std.randf() => x; Std.randf() => y; x*x + y*y => s; } return x * Math.sqrt(-2 * Math.log(s) / s); } " test.ck "Machine.add("/Users/George/Documents/chucko/util/rand.ck"); for (0 => int i; i<10; i++) { rand_norm() => float x; <<< x >>>; } " I add test.ck to the miniAudicle VM and the following error error: line(3): undefined variable 'rand_norm'... Am noob. plz help. kthx. - George

2 2

Re: [chuck-users] chuck-users Digest, Vol 85, Issue 26
by Joel Matthys 26 Aug '12

26 Aug '12

You need parens after closeFile: w.closeFile(); -Joel On 08/26/2012 12:00 PM, chuck-users-request(a)lists.cs.princeton.edu wrote: > Send chuck-users mailing list submissions to > chuck-users(a)lists.cs.princeton.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > or, via email, send a message with subject or body 'help' to > chuck-users-request(a)lists.cs.princeton.edu > > You can reach the person managing the list at > chuck-users-owner(a)lists.cs.princeton.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of chuck-users digest..." > > > Today's Topics: > > 1. WvOut: writes soundfile, but always silent (Click Nilson) > > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

2 1

WvOut: writes soundfile, but always silent
by Click Nilson 26 Aug '12

26 Aug '12

Hi all, Just trying chimera to see what is up in ChucK world. I've found that I can't get WvOut to work; I've tried innumerable permutations, from: chuck curly.ck rec.ck to the code examples below. I can get an output sound file, but it's always silent (though the right length). I've tried different orders of WvOut and dac, and many variations (including wav and aif output). Is this a known problem, or is there some other official way to do this that supersedes the manual included with the distribution? I couldn't find any resolution hunting on old posts from this mailing list. (my system: 10.6.8 OS X) I also find attempting --silent or -s that I just get the system locking up, and a crash on ctrl+c: chuck_oo.cpp:125: failed assertion `m_ref_count > 0' Assertion failed: (libcompiler_rt abort), function __eprintf, file /SourceCache/clang/clang-421.0.60/src/projects/compiler-rt/lib/eprintf.c, line 31. Abort trap best, Nick simple test, from an old chuck-users posting: Noise whitenoise => dac; whitenoise => WvOut waveOut => blackhole; 0.5 => whitenoise.gain; "testchuckoutput"=>waveOut.aifFilename; 2::second => now; waveOut.closeFile; ------------------------------------------------------------------ more complicated (I want to do sample by sample synthesis and write out a sound file): //sample by sample writing of audio in ChucK //for maximal speed in NRT mode, run chuck with -s flag or --silent //e.g. ./chuck /data/sussex/courses/advancedCM/lectures/samplelevel/writesoundfile.ck --silent Impulse i => dac; //=> Gain g dac => WvOut w => blackhole; "chuckoutput.wav" => w.wavFilename; 1 => w.record; //.9 => g.gain; now + 2::second => time later; //workaround to save file on end of synthesis: see examples/basic/rec.ck //null @=> w; while( now < later ) { //set current value of Impulse UGen Std.randf() => i.next; 1::samp => now; } 0 => w.record; w.closeFile;

1 0