2009/1/29 Kassen :

...

How large is n usually in your projects?

Good question. I'm not at home right now so I can't check all my files but typically I try to push it down as far as it will go for projects that require realtime input and leave it at whatever the default is otherwise. I seem to remember I tend to end up with something like 128 or 256 samples or so, not sure.

Why?

Just curious. I wasn't quite sure what you were proposing in your post originally. I thought maybe you were proposing that we find a suitable size for frame and include it in ChucK. But reading it again now, it seems like you're just looking for a way to get a summary of all the Hid input data that was missed during the last frame? Also, knowing your number is interesting. I usually tend toward not pushing things enough. Though I haven't used any controllers that need really tight feedback loops, I usually settle for something closer to 10Hz. -- Tom Lieber http://AllTom.com/

To get back to this for a moment; I was working with this same setup again and so again interested in interpolating data over the span of one block. At some point in a debugging process I had ChucK print the duration (in samples) since the last Hid message at the moment a message arrived. Mostly this resulted in numbers that were either my buffer size or a integer multiple of it but sometimes I got numbers that were slightly off (by a few samples, sometimes as much as a dozen or more) and would (apparently) be compensated for in the next frame. This was on Linux using a RT Kernel, BTW. To me this is a bit odd and slightly disturbing, could anybody with more insight in the internal workings of the engine shed some light on what I might be seeing there? In other news, I'm now convinced that having the duration of the block/frame size as a constant (like "samp") in the language would be a useful thing that we should seriously consider. Clearly it's not something that everybody needs all the time but there are occasions where it is very useful and it would increase the potential portability of code that uses realtime input as the framesize does affect how we can look at incoming data from within the language. Yours, Kas.

Hi, Spencer!

Im not quite sure what you are specifically finding odd/disturbing here--feel free to elaborate further if maybe I missed something.

Hmmm, I was under the impression that events coming from outside of the VM (like HID, MIDI and OSC) were only processed at the start of a new buffer, hence getting them at other times would indicate -to me- something quite odd going on. I wasn't -yet- aware that the VM actually deals with these every sample, which is of course preferable. Clearly what I was seeing was some sort of slight occasional jitter in my OS or in the game device I was using. Considering that I was also running a browser at the same time and that the game controller was quite cheap that sounds like a very likely explanation.

I agree that a buffer size constant is pretty useful; I think this will actually probably be implemented soon since its pretty easy to do.

Great, thanks. One thing I'm now confused about though is the use to this if it turns out ChucK can and does process events in between buffers. I think we should proceed with this as more features are better, especially more meaningful durations but with my new knowledge gained in this discussion I'm now unsure where *you* see the use for this as I'm now no longer sure I see how much buffer sizes will matter from a perspective within the language. Yours, Kas.

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.