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!