[chuck-users] dur frame?

[Kassen]

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.