Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
On 6/30/06, Martin Peach martin.peach@sympatico.ca wrote:
The main factor seems to be that pd only processes control messages in between audio frames.
Do you mean blocks? A few weeks ago someone explicitly said this wasn't true. I don't remember who. He said control messages go when they go, unaffected by audio frames, the audio just doesn't respond to them except between frames.
It's slightly different as I understand this: Control messages get transported every 64 samples, regardless if you set the blocksize lower using e.g. [block~ 1]: It will still get passed every 64 samples.
However Pd also keeps track of time on a much faster scale using its internal "clock", which runs much faster, I think in usecs. Clocks are used for example in [metro] and thus you can run a [metro] with a period of 1msec, even though messages only pass in intervals of about 1.5msec (64 blocks at 44.1kHz). [vline~] is the audio object that can correctly start according to the Clock, if the incoming message is derived from the Clock.
Now I suppose that [hid] does not synchronize to this Clock and thus it is bound to the 64-blocks quantization. I don't know how to "convert" the real time events coming from the HID input to the Clock on Pd, though. Maybe studying m_sched.c very hard can help here.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__