<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_61409" dir="ltr">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.</div><div id="yui_3_16_0_1_1426207280223_116627" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_116624" dir="ltr">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.</div><div id="yui_3_16_0_1_1426207280223_116625" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_116648" dir="ltr">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.<br></div><div id="yui_3_16_0_1_1426207280223_190343" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_190344" dir="ltr">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.</div><div id="yui_3_16_0_1_1426207280223_215298" dir="ltr"><br></div><div id="yui_3_16_0_1_1426207280223_218658" 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 Thursday, March 12, 2015 7:24 PM, Alexandre Torres Porres <porres@gmail.com> wrote:<br> </font> </div> <br><br> <div class="y_msg_container"><div id="yiv5882423478"><div><div dir="ltr">since it was mentioned here, what's the behaviour and deal with [vnsapshot~]? Cause there's no help file for ir yet.<div><br clear="none"></div><div>thanks</div></div><div class="yiv5882423478gmail_extra"><br clear="none"><div class="yiv5882423478gmail_quote">2015-03-12 19:14 GMT-03:00 Charles Z Henry <span dir="ltr"><<a href="" class="removed-link" rel="nofollow" shape="rect" ymailto="mailto:czhenry@gmail.com" target="_blank">czhenry@gmail.com</a>></span>:<br clear="none"><div class="yiv5882423478yqt4329315957" id="yiv5882423478yqt78334"><blockquote class="yiv5882423478gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><span class="yiv5882423478">On Thu, Mar 12, 2015 at 5:01 PM, David Medine <<a href="" class="removed-link" rel="nofollow" shape="rect" ymailto="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>> wrote:<br clear="none">
> @Charles: None of those five sentences is a misconception. When I said 'DSP<br clear="none">
> functions' I meant the functions of the form 'whatever_tilde_perform', not<br clear="none">
> the dsp tick function. I see how this might lead to a misunderstanding.<br clear="none">
<br clear="none">
</span>Sorry if I was unclear as well. We *are* trying to split hairs here,<br clear="none">
of course, just to have an accurate description.<br clear="none">
<br clear="none">
It's not *all* of the dsp functions. I thought this was unclear and<br clear="none">
tried to clarify: rather than scheduling them more often, it actually<br clear="none">
just loops over the sub-graphs multiple times when the block size is<br clear="none">
low. There is always a parent function which is being run once every<br clear="none">
64 samples (the default).<br clear="none">
<span class="yiv5882423478im yiv5882423478HOEnZb"><br clear="none">
> Also, I see that suseconds_t (which is the type of now.tv_usec) is an<br clear="none">
> integer, as I had previously thought, so I am really perplexed as to how<br clear="none">
> [delay] can apparently deliver bangs within less than 1us. I would love for<br clear="none">
> someone to explain this to me. It is a small detail and it doesn't really<br clear="none">
> matter in practice, but I am annoyed when my inferences are not correct --<br clear="none">
> especially when I send them to the Pd list!<br clear="none">
><br clear="none">
><br clear="none">
> On 3/12/2015 1:58 PM, Charles Z Henry wrote:<br clear="none">
>><br clear="none">
>> On Thu, Mar 12, 2015 at 3:18 PM, David Medine <<a href="" class="removed-link" rel="nofollow" shape="rect" ymailto="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>> wrote:<br clear="none">
>>><br clear="none">
>>> Yeah, of course. Block size 1 and high sampling rate will make the timing<br clear="none">
>>> between control and audio super tight (ChucK does this, for example). It<br clear="none">
>>> will also eat the hell out of your CPU. It's a trade off. This is because<br clear="none">
>>> you start calling all the DSP functions once every 1/192k seconds instead<br clear="none">
>>> of<br clear="none">
>>> once every 1.45ms.<br clear="none">
>><br clear="none">
>> This last sentence is also a misconception--the dsp tick function is<br clear="none">
>> called every 64 samples, as commonly defined.<br clear="none">
>><br clear="none">
>> sys_time_per_dsp_tick = (TIMEUNITPERSECOND) *<br clear="none">
>> ((double)sys_schedblocksize) / sys_dacsr;<br clear="none">
>><br clear="none">
>> sys_schedblocksize gets set from DEFDACBLKSIZE<br clear="none">
>><br clear="none">
>> So, the dsp_tick gets called, and when there is a sub-patch with<br clear="none">
>> [block~ 1], it loops over the graph generated from the sub-patch 64<br clear="none">
>> times.<br clear="none">
>><br clear="none">
>> You'd find this behavior coded with the block prologue and epilogue<br clear="none">
>> functions.<br clear="none">
<br clear="none">
</span><div class="yiv5882423478HOEnZb"><div class="yiv5882423478h5">_______________________________________________<br clear="none">
<a href="" class="removed-link" rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a href="" class="removed-link" rel="nofollow" shape="rect" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
</div></div></blockquote></div></div><br clear="none"></div></div></div><br><div class="yqt4329315957" id="yqt11494">_______________________________________________<br clear="none"><a href="" class="removed-link" shape="rect" ymailto="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a href="" class="removed-link" shape="rect" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div> </div> </div> </div> </div></body></html>