[chuck-users] dur frame?

Spencer Salazar ssalazar at CS.Princeton.EDU
Tue Feb 17 05:32:26 EST 2009


Kassen,

Im not quite sure what you are specifically finding odd/disturbing  
here--feel free to elaborate further if maybe I missed something.  HID  
events are received from the operating system in a thread separate  
from the VM thread; upon receiving an event, the HID thread signals  
the VM that the event corresponding to that HID event should be  
broadcasted.  The VM checks for activated events at least once every  
sample.  So the events could really show up at any point in ChucKian  
time; whether its exactly in bufsize intervals depends on how fast the  
HID events are coming in and how much CPU time ChucK takes to  
calculate one full buffer of samples -- less CPU time per buffer will  
lead to greater likelihood of Hid events on buffer boundaries.

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.

spencer

On Feb 16, 2009, at 8:46 PM, Kassen wrote:

> 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.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users



More information about the chuck-users mailing list