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

Re: [chuck-users] hanging server client & mA?
by David Loberg Code 31 Oct '09

31 Oct '09

Sorry Kassen, here is more background. CliX is a piece (by Ge) that is a staple of the PLOrk repertoire. http://plork.cs.princeton.edu/Repository/current/pieces/CliX.zip The members of the group run CliX, which maps ascii on to an Impulse ugen to make little clicky sounds. The conductor runs Clixserver, which sends and receives timing cues so that everybody plays in sync. It should be a simple, pull-out-of-the-box, instant piece for a group to play, but we keep having scattered individuals getting hung up when they are binding with the the server program. david David Loberg Code School of Music Western Michigan University Kalamazoo, MI 49008 code(a)wmich.edu

1 0

Writing multi-channel output to a WvOut
by Andrew C. Smith 31 Oct '09

31 Oct '09

Hey all, I haven't really even looked at this before recently (never wanted to record non-realtime, and just used Jack/Logic before), but now I'm doing stuff that lags badly in real time so I'm running ChucK in --silent. Anyway, how do you write multi-channel output to a WvOut? The UGen specs and examples aren't really clear on this, and whenever I do a dac => WvOut w => blackhole; I get single-channel audio, even when I have the dac running in stereo. Thanks a lot. Andrew

3 2

Re: [chuck-users] Compiling Chuck for Debian (was: Question about unit analyzers)
by David 30 Oct '09

30 Oct '09

Actually, I downloaded the old version from one of the Debian repositories. I guess they don't have the latest version of Chuck yet. If someone has already gone to the trouble of compiling the latest version for Debian, maybe they could just send it to the Debian folk. I'm not sure what the process is for adding a package to a repository. I've compiled small programs of my own before, but I'm kind of reluctant to try building something like Chuck, because of the time, and the need to install any dependencies. I'm running Xandros (Debian-based) on an ASUS eeePC, and from what I understand, it's an old version of Debian, so I might have to install a newer version of gcc, and I don't know what else. I tried the ALSA version of Chuck that you sent me but got an error message about a missing DLL (don't remember which one, and I'm not at home right now so I can't check). Anyway, thanks for all your help. Maybe I'll have some time on the weekend to try downloading the source and compiling it.

2 1

Re: [chuck-users] Question about unit analyzers
by David 29 Oct '09

29 Oct '09

Thanks. I didn't build it, I just downloaded the executable from somewhere. I'll look for a more recent version, or try it build it if I can't find one.

3 5

Question about unit analyzers
by David 28 Oct '09

28 Oct '09

Hi! I'm new to Chuck, and I'm trying to run some of the examples for unit analyzers, but I'm getting an error message like "[ifft2.ck]:line(2): undefined type 'FFT'..." wherever I declare a UA. For example, in this: //chuck.cs.princeton.edu/doc/examples/analysis/fft.ck I'm running version 1.2.0.7 (dracula) under Xandros Linux. It seems to be installed properly, I can run other sample programs using Ugens, read/write audio data, etc. It just seems to be the UA's that aren't working. Any suggestions? Thanks.

3 2

Let's pick up the tweet-length gauntlet!
by Kassen 28 Oct '09

28 Oct '09

Look at what our esteemed colleagues / mortal enemies did; http://supercollider.sourceforge.net/sc140/ Way cool stuff. Should we try our own version? I'm sure we could get the webspace at EM and I'd know a good flash designer who could make us a player. Who's game? Maybe Les feels called to curate this? Les has his radio show with a chat-room that could be used to determine what pieces appeal to a audience and which ones are less popular? Yours, Kas.

7 13

same function name, differing signatures
by Robert Poor 28 Oct '09

28 Oct '09

ChucK complains at the following: // ========== public class FooPie { fun void bark() { <<< "woof" >>>; } fun int bark(int value) { return value * 2; } } // ========== saying "[foo_pie.ck]:line(3): function 'FooPie.bark' matches 'FooPie.bark' but cannot overload..." This seems odd to me. bark(void) and bark(int) are two different functions -- aren't they? -- so why should ChucK require them to have the same return type? (Perhaps I'm just pining for Objective C, where the internal function names would be FooPie.bark:void and FooPie.bark:int which are clearly different functions.) Unless Ge thinks this is a bug, I'm really only looking for an explanation as to whether or not foo(void) and foo(int) are the same function or not. Or at least how to think about functions with the same name with different argument signatures. - Rob

1 0

Dyno docs erata
by Kassen 23 Oct '09

23 Oct '09

The online docs ( http://chuck.cs.princeton.edu/doc/program/ugen_full.html#Dyno ) say; - *.attackTime* - ( float, READ/WRITE ) - duration for the envelope to move linearly from current value to the absolute value of the signal's amplitude - *.releaseTime* - ( float, READ/WRITE ) - duration for the envelope to decay down to around 1/10 of its current amplitude, if not brought back up by the signal The type should instead be "duration". This is slightly relevant-ish as some of the STK UGens would express times in float. I think we got most of those by now but it can't hurt to keep such confusing inconsistencies to a minimum. Yours, Kas.

3 2

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