<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1426207280223_722485">You're measuring many things at once:</div><div id="yui_3_16_0_1_1426207280223_722484" dir="ltr">1) lower limit of [metro] granularity, which is much higher than other clock-based objects in Pd like [del] and [pipe]</div><div id="yui_3_16_0_1_1426207280223_705959" dir="ltr">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)</div><div id="yui_3_16_0_1_1426207280223_601092" dir="ltr">3) probably something having to do with Pd's hard-coded default dac block size of 64</div><div id="yui_3_16_0_1_1426207280223_609075" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_617580" dir="ltr">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.</div><div id="yui_3_16_0_1_1426207280223_631594" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_645773" dir="ltr">As far as measuring the smallest "grain" with which you can trigger clock delays in Pd-- I guess there are two answers:</div><div id="yui_3_16_0_1_1426207280223_633761" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_633762" dir="ltr">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.</div><div id="yui_3_16_0_1_1426207280223_726620" dir="ltr"><br></div><div dir="ltr">The other answer is based on my shaky understanding of m_sched.c. Here goes...<br></div><div id="yui_3_16_0_1_1426207280223_726622" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_633760" dir="ltr">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.<br></div><div id="yui_3_16_0_1_1426207280223_691760" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_697763" dir="ltr">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.</div><div id="yui_3_16_0_1_1426207280223_732831" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_732832" dir="ltr">Since mortals are so inept at measuring time on that level, precise bookkeeping is probably precision enough.</div><div id="yui_3_16_0_1_1426207280223_724554" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_724555" dir="ltr">-Jonathan<br></div><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font face="Arial" size="2"> On Friday, March 13, 2015 1:59 PM, Martin Peach <chakekatzil@gmail.com> wrote:<br> </font> </div> <br><br> <div class="y_msg_container"><div id="yiv3235604722"><div dir="ltr">On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres <span dir="ltr"><<a href="" class="removed-link" rel="nofollow" ymailto="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span> wrote:<br><div class="yiv3235604722gmail_extra"><div class="yiv3235604722gmail_quote"><blockquote class="yiv3235604722gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><div dir="ltr"><span class="yiv3235604722"><span style="font-size:12.8000001907349px;"></span></span><span class="yiv3235604722"></span><div><span style="font-size:12.8000001907349px;">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.</span></div><div><br></div><div><span style="font-size:12.8000001907349px;">But yeah, I think everyone gets the question anyway, but the final detailed answer is still out there somewhere.</span></div><div><span style="font-size:12.8000001907349px;"><br></span></div><div><span style="font-size:12.8000001907349px;">This is what I get so far, anyway: </span><span style="font-size:12.8000001907349px;">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 </span><span style="font-size:12.8000001907349px;">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.</span></div><div><span style="font-size:12.8000001907349px;"><br></span></div><div><span style="font-size:12.8000001907349px;">By making it more straightforward, </span><span style="font-size:12.8000001907349px;">it has no limits, </span><span style="font-size:12.8000001907349px;">it can go faster than you'll ever need it to until it kills your CPU.</span></div><div><br></div></div></blockquote><div>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.<br><br></div><div>Martin<br></div></div></div></div></div><br>_______________________________________________<br><a href="" class="removed-link" ymailto="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a href="" class="removed-link" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br><br><br></div> </div> </div> </div> </div></body></html>