[chuck-users] multi-channel dac/adc?

[Ge Wang]

Hi Charlls!

Welcome!

> 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 
about!)

> 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 
multi-channel audio.

> 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;

Cool!

Best,
Ge!