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:
- 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...
- 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:
On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres porres@gmail.com wrote:
About the "control rate" paradigm in Pd, I have to admit that when I asked about it I was thinking about it in relation to what that means in supercollider and Csound, but I also always considered that Pd doesn't really have that kind of "control rate" per se. It's nice that we can look deeply into what it all means in the Pd context. But yeah, I think everyone gets the question anyway, but the final detailed answer is still out there somewhere. This is what I get so far, anyway: By thinking of more of a general concept from the SC/Csound realm, a control rate is something that is slower than audio rate and it doesn't make sense that it can go higher than audio rate (thus some may consider it "curious"). Simply put, since Pd does not have this kind of paradigm in its structure, control messages have no real boundary and are free to be fired at any rate that your computer can manage and restricted only to bit float limitations. By making it more straightforward, it has no limits, it can go faster than you'll ever need it to until it kills your CPU.
The attached patch lets you see Pd's "control rate" in action. It shows a graph of a wave being chopped at control rate. It won't chop any faster than about 1ms and it's irregular.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list