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

ChucK highlight script for SciTE
by Szilveszter Tóth 03 Nov '09

03 Nov '09

Hello All, I have found "highlight scripts" (or whatever we call them) for VIM and for JEdit on the web page, but I'd like to stick to SciTE, which I like the most. However, it does not seem to know ChucK... Does anyone have a SciTE .properties file for ChucK or should I make one? BTW, selecting "Java" as the language highlights keywords quite well. Regards, Szilveszter (aka Hillaby)

4 7

hanging server client & mA?
by David Loberg Code 31 Oct '09

31 Oct '09

Clixserver has been so temperamental. It often happens when new clients are added, that a couple of people will have their CliX get hung up in between "mouse ready" and "keyboard ready". (Everyone else will be fine and clicking away.) I can't identify an obvious reason (e.g., they are listening on the wrong port number). It seems more likely to happen if mini-Audicle is on or was used recently. Is that plausible? (Obviously we're not running CliX in mA, since KBHit doesn't work there.) thanks in advance, david David Loberg Code School of Music Western Michigan University Kalamazoo, MI 49008 code(a)wmich.edu

4 9

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