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

Re: [chuck-users] chout and cherr confuse me [BUG?]
by Spencer D Salazar 21 Oct '09

21 Oct '09

Howdy, While there should be no debate that stdout buffering is a nearly universal implementation strategy of C/C++ IO, the exact behavior Kassen is reporting was concerning to me. I then remembered that one common detail in how stdout is buffered is that the buffer is flushed less often when stdout is directed to a file or a pipe. It just so happens that to enable the Console Monitor, miniAudicle has to redirect stderr and stdout to a pipe. As far as I can tell, Kassen's original example works fine in command line chuck. As you have reported, not so much in the mini. I think the fix for this is pretty straightforward, so that should be in SVN shortly*. Kassen, thanks for reporting this and sticking to your guns! spencer * By the way, miniAudicle's active source repository has moved to SVN, hosted by Google Code. ----- "Kassen" <signal.automatique(a)gmail.com> wrote: > Hi, Ge! > > > > > > In short, chout prints to stdout (buffered output, higher > performance), and cherr prints to stderr (more timely and synchronous, > handled differently by console/pipes/redirect). The existing <<< >>> > operators prints to stderr by default (there was actually no way to > print to stdout before chout). > > > > Check, that's quite clear then. > > > If one desires truly synchronous output, then cherr is probably the > way to go. At the same time, there are a few nuances of cout (C++) - > there is a method to force flushing the buffer - this actually exists > for chout - just invoke .flush(). Inserting an "endl" into C++ cout > effectively flushes the output stream - this is currently not > implemented. I've made > this addition in CVS (IO.newline() or "\n" by itself will cause a > flush on chout), and this should be in the next release. > > > Well.... now I have a new issue; > > chout.flush(); > > ...will crash the Mini for me. It even crashes when that's the only > line in the file. > I'm also sorry to have to say that I'm still not sold on the idea that > chout works properly. I can accept it being slow but here it is being > slow in a very predictable way that's related to what ChucK does. > Especially as IO.newline() doesn't seem to -by itself- flush all data > out. If you look at my example code you'll see all print commands use > newline() yet at the end of running the file there is still a print > command up in limbo. > > Sorry to persist like this. > > Yours, > Kas. > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

3 3

chout and cherr confuse me [BUG?]
by Kassen 21 Oct '09

21 Oct '09

Fellow ChucKists, Consider this edit of one of the new examples, I just made this because I was trying to figure out the difference between chout and cherr and why the plain example's output had the order in which the results of the operations were printed reversed; ---------------------8<-------------------------- // 'chout' is chuck out, pronounced "shout" // 'cherr' is chuck err, pronounced "Cher" // output to console on stdout chout <= 1 <= " foo " <= 5.5 <= IO.newline(); // output to console on stderr cherr <= 2 <= " bar " <= 5.5 <= IO.newline(); <<<"start pause">>>; second => now; <<<"end pause">>>; // output to console on stderr cherr <= 3 <= " bar " <= 5.5 <= IO.newline(); // output to console on stdout chout <= 4 <= " foo " <= 5.5 <= IO.newline(); -----------------------------8<-------------------------------------- Now, the output this gives varies with how many times we used the various commands in the recent past and on what, but it stabilises to this after running it a few times; [chuck](VM): sporking incoming shred: 1 (*chout.ck)... 2 bar 5.5 "start pause" : (string) 4 foo 5.5 1 foo 5.5 "end pause" : (string) 3 bar 5.5 It seems to me that chout has some sort of internal buffer and that it takes two chout commands to reach the actual console, instead of one, like I expected. It also seems like cherr has a higher priority of some sort. maybe cherr commands print immediately while chout ones are delayed until time is advanced? I'd like to know what the intended behaviour is as I'm now just guessing about the difference between the two. Right now I'm leaning towards suspecting at least a bug in chout. Yours, Kas.

6 17

ASIO cross-compile (paging dr. Sinclair!)
by Kassen 20 Oct '09

20 Oct '09

Fellow ChucKists/ Dear Stephen. Some time last year there was some talk about using GCC on Linux to build ChucK for Win32. This would be useful for things like a ASIO build, testing minor tweaks, etc. This is a big deal to me; I need ASIO for live performance as the default drivers are SLOOOOOW and stereo only, I don't like to have to beg for new ASIO builds and finally; there is a real interest in this. The ASIO versions kept on the Electro-Music forum were downloaded between about a hundred and over three hundred times each, those numbers seem quite signifficant to me. So; time to get my hands dirty. The sensible solution would be to get MS's free compiler but my Win XP install is so severely stripped that I don't dare install any big MS packages. Right now it's very stable and I'd like to keep it that way. So, at Stephen Sinclair's recomendation I got the MinGW packages.... and now I seem to be stuck. MinGW *seems* to be capable of building Win32 programs but it's not so clear to me how one would go about that. How would I move from here? Yours, Kas.

2 1

Korg nano keyboard.
by Reg Id 18 Oct '09

18 Oct '09

1 0

Korg nonoKontrol as an input device
by Robert Poor 18 Oct '09

18 Oct '09

A guy in my band just showed me his new Korg nanoKontrol -- $60 gets you nine sliders and nine encoders in a slick compact package: http://createdigitalmusic.com/2009/08/18/nanokontrol-myr-for-ableton-live-f… I tried opening it in ChucK as a Hid joystick and as a MIDI keyboard, but no luck. Has anyone used a nanoKontrol with ChucK? And if so, what's the secret? It would be a nice addition to a live setup. -- Rob

3 6

Re: [chuck-users] Wrapping ChucK
by Hans Aberg 18 Oct '09

18 Oct '09

It was just my impression from the Wikipedia site. Also note that there is GNUstep: http://en.wikipedia.org/wiki/GNUstep The screenshot of GNUMail looks very similar to that of Mac OS Mail, and both derive from NeXTMail. - I'm getting skilled at using the shift key! The point would be to just doing one multiplatform GUI. Hans On 17 Oct 2009, at 23:19, Andrew C. Smith wrote: > Interesting -- I don't think they're actually deprecated, though, but > they're compiled versions of the .xib files. The .xibs are encoded in > XML format, so that then when you compile the interface it becomes a > .nib. > > Kas, good call on that. Pretty sure I Am T-Pain is not open source, > though, seeing as how it's one of the top-selling apps, along with > Ocarina. (btw--Ocarina sounds very "ChucK." Agree or disagree?) > > If anyone is following this, I found a gem in audicle_nexus.cpp under > the function chuck_chuck( int argc, char ** argv, t_CKBOOL co ), which > is what the audicle uses to start up chuck. I'm working now on > importing the new ChucK into Xcode, after which I'll start to see if I > can link it to some simple Cocoa program. > > Andrew

1 0

Wrapping ChucK
by Andrew C. Smith 17 Oct '09

17 Oct '09

Has anyone tried to wrap ChucK into a standalone program? I'm thinking (at the very least) it could just be made to run simultaneously and communication could be made over OSC, but it would be cool to have the whole thing communicate through 8888, the port that the console communicates on. Basically, the mini is an effective wrapper, right? I'm just wondering if anyone has created anything simpler, like even just a program that outputs ChucK sounds when you click buttons or something. It would be really cool for games (or toys, not really games) that let users play around with sounds using an integrated graphical interface. Anyone try it? Andrew

9 19

feeble time printing
by Robert Poor 16 Oct '09

16 Oct '09

I'm pretty sure there's a bug in the way ChucK prints time. Or there may be a bug in the way I think. Bear with me... You would expect that two time values that print identically would compare as equal. But I can show you a case where t0 and t1 print as "44100.000000" yet they're not equal. You'd also expect t1 to have a fractional part of 0.0. But in this case: <<< (t1 % 1::second) >>> prints "1.000000" and <<< t1 - (t1 % 1::second) >>> prints "44099.000000" Mind you, I'm NOT complaining about roundoff error -- I understand that converting between floats and time is subject to roundoff -- but it has certainly cost me a LOT of debugging time discovering that 44100.000000 != 44100.000000. It's a printing bug. Here's the code. It's longer than it needs to be, so if anyone asks for it, I'll strip it down to a three line example. // In ChucK, two times can appear to be equal when printed, // but compare as not equal, as demonstrated here. 72.511111111 => float tempo; // intentionally subject to roundoff now => time t0; // base time 100.0 => float b0; // beat at t0 1::second / tempo => dur i0; // duration of one beat // convert from system time to beat fun float time_to_beat(time t) { return b0 + (t - t0)/i0; } // convert from beat to system time fun time beat_to_time(float b) { return t0 + (b - b0)::i0; } // for debugging: extract fractional and whole parts from time fun dur frac_time(time t) { return t % 1::samp; } fun time whol_time(time t) { return t - (t % 1::samp); } fun void test_time(time t0) { beat_to_time(time_to_beat(t0)) => time t1; if (t0 != t1) { <<< "t0:",t0,"is not equal to t1:",t1>>>; frac_time(t0) => dur f0; frac_time(t1) => dur f1; whol_time(t0) => time w0; whol_time(t1) => time w1; <<< f0, f1, f0==f1, w0, w1, w0==w1 >>>; } } test_time(now); test_time(now+1::second); test_time(now+1::samp);

2 1

The ChucK Game Show
by Les Hall 13 Oct '09

13 Oct '09

The iTunes debut of The Game Show went well and there was plenty of ChucK to be heard. Next week: a special all-ChucK Game Show! Tune in on iTunes by clicking on radio in the upper left, selecting the electronica genre, then scrolling down and selecting radio.electro-music.com at 7pm EST (4pm left coast time). New additions to the show: the penalty box and the Keystone Cops! Anyone in the chatroom who breaks the rules or misbehaves (which is often on THIS show) has to go into the penalty box. If they make a run for it, the Keystone Cops go after them, with their big floppy clown shoes and nerf batons! Last week Jan got locked in the penalty box but he enjoyed it because Sunshine was in there with him and shared her "cookies" fresh from the oven with him. Rob won, but that is debatable because he cheated as usual and the show was fixed! Oh no! Tune in for plenty of chaos and mayhem! Les

1 0

Re: [chuck-users] problems using quicktime synth
by Hans Aberg 11 Oct '09

11 Oct '09

[You are forgetting to cc the list.] OK. The update to the QT version you have torched QT, but I suspected it has to do with the filesystem - I use the case-sensitive one. In the past, when this has been a problem, it has affected both PPC and Intel computers, people assuming it has to do with an installed sound component. Anyway, in order to test if it is QT or ChucK, you might try SimpleSynth with some MIDI gear. Hans On 11 Oct 2009, at 14:36, David Minor wrote: > Mac OS extended journaled > > On Sun, Oct 11, 2009 at 2:28 PM, Hans Aberg <haberg(a)math.su.se> wrote: > On 11 Oct 2009, at 14:20, David Minor wrote: > > OSX 10.5.8, Quicktime 7.6.4, Filesystem HFS. > > If you go to Finder, click on the hard drive icon, and selects Info > <cmd>-I, what does it say that the format is? - Alternatively, open > Disk Utility, and check this. > > Hans > > >

2 3