Ge Wang;
We would like to conduct a N-part user study (where N >= 1)
Excelent. I'll go be the degenerate case for this equation then.
on using ChucK. To start, we are interested in learning about how everyone is using ChucK,
I've been using the plain command prompt version. Audicle is a work of art but aparently my video card isn't. Mainly I've been building custom sequencers and beat mangeling devices controlled in realtime by the keyboard, MIDI and recently a joypad as well. The otf commands at the moment seem too indirect to me to be satisfying as a instrument on their own. Random-ness doesn't apeal to me on a compositional level so realtime controll it is. The OTF commands flush my prescious arrays and we can't have that. This may change as global data and command line parameters arrive. Basically I've been building the sort of thing I miss in Live and Renoise, primarily to treat and play samples. One structure I use a lot is having a "step" parameter and increase that as I chuck to now. I then use this as a index to arrays and write all sorts of stuff to the arrays in various ways. Currently I like arrays much better then traditional sequencers. the problem with sequencers is that they tend to asume a "composition" style of taking input and not a "musician" style. The Serge TKB is the one sequencer I like a lot but it lacks S&H type structures and it's also about a order of magnitude out of my financial range.
the ways (if any) ChucK has effected the way you write/think about audio programming, and/or your thoughts on ChucK.
I have to admit that ChucK didn't change the way I think about audio processing or programing in the slightest. Oscilator => filter => output Looks comparatively good compared the equivalent in Csound (or even the pannel of a arp 2500!) but it's not all that different, you can do the same everywhere (and that's good). It did however profoundly change the way I look at controling sound, particularly as time is concerned. My current main ChucK project uses a interface where I am always slightly ahead of realtime, cueing up a series of events, then doing something else while they execute. Also good is that for some reason ChucK is very intuitive and easy to program in. I find I can prototype new ideas very quickly. Where in the past I'd lament the lack of a feature in a tool I can now generally make my own and have it within two or three hours. Another good thing is that ChucK has a very small user base (you may disagree there...) which means you can talk to the developers directly. I don't think Cubase's lead programer is looking to get emails from all users that discovered they have some issue two minutes ago and I imagine that if he did he probably wouldn't reply with links to a updated binary. Finally; MAX and SC fanatics seem to think ChucK users are inherently clinically insane. Actually even my label boss seem to think it's a insane idea to plan on performing with homebrew stuff since it may crash. I suppose that's true, but other things may crash too and other things tend not to be able to conveniently go "if(maybe) machine.crash;" Not so good is that ChucK is heavy on the CPU but I agree with Perry that the main apeal is the way it works and this should get priority over optimistation. I'd like to chime in with your request for feedback because beyond the custom editors I have no idea at all what anybody else is actually doing with this stuff. Kas.