[chuck-users] user study!!!

Kassen signal.automatique at gmail.com
Tue May 23 11:14:58 EDT 2006


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.


More information about the chuck-users mailing list