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

Re: [chuck-users] Begin the beguine (Alberto Alassio)
by Perry Cook 01 Oct '12

01 Oct '12

Hey all, I'll pipe in here with a set of course notes I put together for a workshop/tutorial on "Sonification in ChucK" It steps through chuck from Hello Sine through functions and built-in math.foo() and std.bar() functions through much more. It is, I believe, the most short yet complete list of things you can and should do with ChucK. Not everything is explained, of course (it was only a 2 hour tutorial). It's all on a sub-directory of my main web page called "ChucK U!" See: http://www.cs.princeton.edu/~prc/ChucKU/ The notes are at: http://www.cs.princeton.edu/~prc/ChucKU/SonifyingInChucKICAD2012.pdf but if you go to the main ChucKU page, you'll see code examples, links to other things, etc. PRC

4 3

Begin the beguine
by Alberto Alassio 30 Sep '12

30 Sep '12

Hi guys this is my first thread because I've download Chuck just yesterday night and I'm trying to make something with this today (yes we can!). Really nice world! I read something from the manual ( the beginning tutorial) and also downloaded chuck pages where objects and other things about language are written. The question is : how can I understand every single line of Chuck? And I'm gonna make an example: foo.ck example. I was looking at this and also to other ones to understand how they work but... I saw that there are objects that are explained in Chuck homepage (sinOsc, delayD, etc) but where can I find informations about Std? Hi?How can I understand what does Hi.cap mean? These are just examples, is there a place where every command is explained? Or maybe (and probably) it's just me not so good searcher? Thank you everybody Balbit

5 23

Looping
by Alberto Alassio 27 Sep '12

27 Sep '12

I cannot understand how the while structure has to be used. I mean, I understood that while ( true ) means infinite loop and also that while ( n::second => now ) means an "n" second loop duration but... If I just want to do a really stupid thing like a Sine at 220 Hz that sounds for 2 seconds and then stops for 2 seconds and then goes again. How could I do? I thought that it was necessary just to do something like this SinOsc s => dac; .2 => s.gain; 220 => s.freq; while ( 2::second => now) 0 =>s.gain but I know that it's not the right way, also because in this method I would have to rewrite this thing an infinite ( whiletrue ahahah) number of times to have what I'm looking for. And I don't actually understand {} . How am I supposed to use these? Thanks

4 13

1.3.1.2 (chimera) released!
by Ge Wang 21 Sep '12

21 Sep '12

Greetings all! chuck-1.3.1.2 (chimera) is available: http://chuck.cs.princeton.edu/ http://chuck.stanford.edu/ This release addresses some of the recent issues discussed on this list, includes 2 important bug fixes, and adds automatic sample rate detection for JACK as well as others. release notes are copied below. Once again, thanks to everyone who reported issues and helped to track things down and test! Please continue to let us know if you run into any issues! Thank you and keep on ChucKin'! Best wishes, Spencer, Ge + on behalf of chuck team! 1.3.1.2 --- - (added) chuck now automatically detects and uses next highest or closest (in that order) system sample rate in the case where the default is not available; if a sample rate requested via --srate: is not available, an error will be encountered with a message. - (fixed) base parent object is correctly accounted for by new shred when sporking member functions (thanks to Michael Heuer for reporting and narrowing this down) - (fixed) popping local variables from the operand stack in cases where the datatype size is larger than int-size; this is a bug introduced with 64-bit in 1.3.1.0, and exhibited on 32-bit systems only. (thanks to Simon Steptoe reporting and narrowing this down) - (fixed) opening real-time audio with 0 input channels should now work, once again.

3 3

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