Hallo, brandon zeeb hat gesagt: // brandon zeeb wrote:
For example:
- If I am attempting to send a message every 8msec (5.51 dsp blocks), will
the event actually be sent, rendered, and perceived to occur every 8msec or will it be rounded up to the next block ( #6 ) at 8.7msec?
If you send the message from a clock-object like [metro] it will be sent every 8 msec. "Rendered" and "perceived" are ambigous terms here that don't have much value without additional info on what exactly you mean by them (best do a patch).
- If an event is scheduled to occur every 1.50msec, will it be scheduled in
time every 1.50msec or every 2.90msec?
It will be scheduled every 1.5 msec. Or rather, it will be scheduled whenever Pd thinks it has time to schedule it, but you can depend on it to "happen" every 1.5 msec of Pd's internal scheduler time, not at some other time.
Pd has an internal clock, which is what drives [metro], [delay], [pipe], [timer] and some other objects. This "clock time" is as accurate as the resolution of numbers in Pd is (32 bit) and it is not quantized to any blocks.
However the difficulties start as soon as you convert from messages to audio signals (and back). Most dsp objects in Pd operate on block boundaries, so they are quantized.
For example if you try to build a fake phasor~ from a [line~] object and a fast [metro], the frequency will jitter around the block size.
Often this doesn't matter (because you'd use a phasor~ anyway), but if it should matter, you have to use one of the special audio objects that correctly interpret clock-messages without any block quantization. Instead of [line~] you just use [vline~] and your fake phasor~ will be perfectly in tune.
You don't need to do anything special when just dealing with messages without conversions to dsp. Note that events coming from the GUI (mouse clicks) are quantized to be read every 64 samples.
Ciao
Frank