I'm not sure that the precision of clock-based classes (float for Pd users, double within the external API) or even Pd's event loop should be considered part of the topic "control rate". That term already means something in Csound and Supercollider, something like a rate for gaining efficiency by letting objects copy a scalar value for the entire block instead of computing each sample. For example, if you want to use a low frequency sine wave to attenuate some noise, you can compute one value of the sine wave per block and just copy it for each sample of that block. That will be more efficient that computing each sample, and still be fast enough to avoid zipper noise.
In Pd, some of the math signal objects from d_math.c do something similar in nature. For example, [*~] has two signal inlets, but [*~ 0] has a control inlet on the right. That control inlet limits the maximum speed with which you can change the stored value (i.e., once per block). It's also presumably more efficient than [*~] because one of the increment operators is replaced with a single float variable.
But that's still not really "control rate", because control objects don't have a requirement to fire on a set schedule. I guess making a chain of control objects below [bang~] would be the closest thing to Supercollider's "kr" method. But because of Pd's message-passing overhead that's probably not going to be as efficient.
But maybe the question is this: what is the smallest interval one can specify in Pd to reliably trigger messages through time? The answer is probably inside m_sched.c, but I can't figure it out with a casual glance. However, it looks to be dependent on the sample rate you choose, as the lowest common multiple of the common sample rates is used to calculate the granularity of the time units themselves.
-Jonathan
On Thursday, March 12, 2015 7:24 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
since it was mentioned here, what's the behaviour and deal with [vnsapshot~]? Cause there's no help file for ir yet.
thanks