You're measuring many things at once:
1) lower limit of [metro] granularity, which is much higher than other clock-based objects in Pd like [del] and [pipe]
2) common way in which control messages are converted to signals on the block boundaries (the other way is how vline~ and vsnapshot~ do it)
3) probably something having to do with Pd's hard-coded default dac block size of 64
You can get rid of #1 by using a [delay] loop instead. But be careful-- if you accidentally set it to "0" then unlike [metro] it will carry out your instructions.
As far as measuring the smallest "grain" with which you can trigger clock delays in Pd-- I guess there are two answers:
1) For practical purposes, this seems to be limited only by the precision with which you can specify delays to Pd. As a patch author, that would be the float precision, or for Pd Double, double precision. If you're an external developer, you send a double to clock_set.
The other answer is based on my shaky understanding of m_sched.c. Here goes...
2) The Shrunken Omniscient Demigod answer-- let's say you shrink down and stand next to the CPU to watch Pd's instructions fly by. You might notice that some [delay] triggering instructions arrive too closely together, while others are spaced too far apart. Since you're omniscient you would know this happens because the triggering of the control events are quantized to the dsp "tick" time (i.e., sys_time_per_dsp_tick). That means two delays that both happen before the next tick will get triggered one right after the other, while two separated by a block boundary will happen with a delay of one block.
Since you're omniscient, you would also know that the timestamps are not quantized to the dsp "tick" time. That means that Pd keeps track of and reports the correct timings with [timer] and friends regardless of how the block boundaries interact with the actual timings of control events firing in an object chain.
Since mortals are so inept at measuring time on that level, precise bookkeeping is probably precision enough.
-Jonathan
On Friday, March 13, 2015 1:59 PM, Martin Peach <chakekatzil@gmail.com> wrote: