Spencer;
Cool, glad I could shed some light here.
BTW, I feel that some of these interactions between ChucK and the OS affect ChucK's behaviour to such a degree that we should probably go into them in the documentation. So far all the docs have focussed on just ChucK's internal behaviour as it appears to the user. Things like Windows's 8 axis maximum for joystick HID devices can and will affect what we can do with ChucK. As an aside; I'm not sure how I got this wrong idea about devices and buffers at all, I really seem to remember this was mentioned by somebody but now I can't recall where. Oh, well, at least it's clear now.
In situations where CPU is at a premium, specifying control rates in terms of integral multiples (or integral divisions) of the buffer size can have significant effects on audio reliability and responsiveness of anything else running on the same system. This isn't really noticeable on the modern multi-core desktop/laptop (perhaps a case for not making this a standard feature), but can be quite relevant to phone/netbook/embedded environments.
Good point. I see two good reasons to make this a standard feature. For one thing I think that we should have as much relevant info as possible available within the language. Frame-size is there and so I think it should be available, just like I also feel the time of day should be available in some way and now that I think of it the HID poll-rate, likely on a per-device basis as part of the specs even if I do think Windows sticks to a single rate for all devices instead of the proper way of asking the device at what rate it can/should be polled. Another potentially interesting bit of information could be the host OS. Without knowing the host OS it will be hard or impossible to use Std.system() in a portable way. As a example; a unpleasant surprise I ran into yesterday is that Linux turns out to have a very different opinion on one of my Playstation => USB converters than Windows does, replacing the hat switch with two axis. If I could poll the OS for it's name it would be easier to have code that is both portable and clean. These bits of info should be there already on some level or be easy to obtain and IMHO very useful. The second reason that I see is that netbooks/phones/embedded devices are exciting to work with. A few days ago I tried the keyboard of a Asus EEE and while I think it's cute and I'm of course in favour of that kind of mainstream distribution of Linux it's not the kind of keyboard I'd like to write a lot of code on, and that's without even going into phone interfaces. I envision that a lot of code meant to run on devices like that might be (primarily) developed on desktops and larger laptops. Because of this I can see benefits in keeping a mobile ChucK (MucK?) as syntactically close to the main branch as possible for easy prototyping even if what benefits embedded devices performance-wise might not make a big difference to a multi-core/cpu workstation. Thanks again for your help and insights, Yours, Kas.