[chuck-users] multi-channel dac/adc?
gewang at CS.Princeton.EDU
Fri Feb 10 17:51:25 EST 2006
> I wonder if it is possible to manage input and output of audio
> hardware with more than 2 channels,
Not yet, though we are working on enabling this. We need
this pretty badly since we are using ChucK to teach the
Princeton Laptop Orchestra, and each station has 6 channels
hemispherical speakers... Hopefully this will be done in the
next few weeks.
> this relates to a secondary doubt it's tickling me; why there seems to
> be a embedded version of stk inside chuck source, instead of relying
> on stk as a external dependency?
1) simplified build - by default, all source files are in one directory
and builds out-of-the-box. furthermore, chuck is supported on MacOS X
and Windows, in addition to linux. Each platform (especially windows)
potentially has its own idiosyncrasies.
2) we have slightly modified some of the STK source to facilitate
importing into chuck. also, some of the raw sound files needed by
several STK instruments are now statically compiled into chuck - again
we are going for things working right out-of-the-box.
External dependencies, of course, have advantages, such as loose
coupling. In the case of libsndfile, for example, we both provide a
pre-configured libsndfile (default for osx and win32), as well as the
option to link against external libsndfile (default for linux). In the
the case of STK, it made more sense (at some point) to "embed" a
modified version of it. Working "out-of-the-box" as much as possible
is really important, we think (chuck has enough other problems to worry
> Currently stk 4.2.1 supports any number of audio I/O channels,
We are indeed using RtAudio for real-time audio, but as a totally
separate component from the synthesis algorithms of STK. We have also
slightly tweaked RtAudio to fit our needs. We need to change key spots
in the ChucK synthesis engine and UGen language API to enable
> it's possible to easily update chuck to support the new stk?
We do updates to ChucK's STK objects by hand, as needed. If you need a
STK feature not currently available in ChucK, let us know. We are
actually making a ton of additions to chuck's STK API for the next
version, exposing many new functionalities.
> or even cleaner, move stk as a external dependency?
For the above reasons, it makes more sense to embed STK in ChucK, at
least for now. What is cleaner is not necessarily better in this case.
At any rate, these are certainly great questions. We are not stapled
to any single way of doing things, so if there are compelling reasons
to change, we are open to do so. Thanks.
> p.d: for gentooers, there are now two (preliminary, they work on my
> x86 box tho) ebuilds for stk and chuck;
More information about the chuck-users