<div dir="ltr"><span class="im" style="font-size:12.8000001907349px">>> I thought there was a limit control rate that was below </span><div><span class="im" style="font-size:12.8000001907349px">>> the audio rate, but <span class="">curiously</span> it can go over.<br></span><span style="font-size:12.8000001907349px">> That is what I'm trying to say since - I don't know - at </span></div><div><span style="font-size:12.8000001907349px">> least three </span><span style="font-size:12.8000001907349px">posts.</span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">And I understood that even before I asked to the list in my first email, when I first mentioned that the fact was curious. By the way, I'm still finding it quite curious. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><div><span style="font-size:12.8000001907349px">> [timer] shows the correct number. However, even that</span></div><div><span style="font-size:12.8000001907349px">> simple </span><span style="font-size:12.8000001907349px"> patch clogs </span><span style="font-size:12.8000001907349px">my CPU when setting it to 1e-06</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I'm aware that CPU can choke on an absurdly fast control rate. Nonetheless, the concern and question is not to how much the CPU can take, but how small a period of time Pd could consistently and steadily send messages. To make it simple, the smallest time an object like [metro] is able to operate.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">If [timer] calculates that period of time correctly and accurately, then I was able to go get consistent results at around 1e-09, where the values between metro time and [timer] kinda mismatch and it stops being accurate.</span></div></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><i>> But maybe the question is this: what is the </i></span></div><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><i>> smallest interval one can specify in Pd to </i></span></div><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><i>> reliably trigger messages through time?</i></span><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><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>cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-12 23:47 GMT-03:00 Jonathan Wilkes <span dir="ltr"><<a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div 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 dir="ltr"><br></div><div 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 dir="ltr"><br></div><div 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 dir="ltr"><br></div><div 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><span class="HOEnZb"><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">-Jonathan<br></div></font></span><div><div class="h5"><div><br><br></div><div style="display:block"> <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"> On Thursday, March 12, 2015 7:24 PM, Alexandre Torres Porres <<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>> wrote:<br> </font> </div>  <br><br> <div><div><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><br clear="none"><div>2015-03-12 19:14 GMT-03:00 Charles Z Henry <span dir="ltr"><<a rel="nofollow" shape="rect">czhenry@gmail.com</a>></span>:<br clear="none"><div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Mar 12, 2015 at 5:01 PM, David Medine <<a rel="nofollow" shape="rect">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><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 rel="nofollow" shape="rect">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><div>_______________________________________________<br clear="none">
<a rel="nofollow" shape="rect">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
</div></div></blockquote></div></div><br clear="none"></div></div></div><br><div>_______________________________________________<br clear="none"><a shape="rect">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div>  </div> </div>  </div> </div></div></div></div></blockquote></div><br></div>