[PD] maximum "control rate" in Pd

[Jonathan Wilkes]

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 at 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
2015-03-12 19:14 GMT-03:00 Charles Z Henry <czhenry at gmail.com>:

On Thu, Mar 12, 2015 at 5:01 PM, David Medine <dmedine at ucsd.edu> wrote:
> @Charles: None of those five sentences is a misconception. When I said 'DSP
> functions' I meant the functions of the form 'whatever_tilde_perform', not
> the dsp tick function. I see how this might lead to a misunderstanding.

Sorry if I was unclear as well.  We *are* trying to split hairs here,
of course, just to have an accurate description.

It's not *all* of the dsp functions.  I thought this was unclear and
tried to clarify: rather than scheduling them more often, it actually
just loops over the sub-graphs multiple times when the block size is
low.  There is always a parent function which is being run once every
64 samples (the default).

> Also, I see that suseconds_t (which is the type of now.tv_usec)  is an
> integer, as I had previously thought, so I am really perplexed as to how
> [delay] can apparently deliver bangs within less than 1us. I would love for
> someone to explain this to me. It is a small detail and it doesn't really
> matter in practice, but I am annoyed when my inferences are not correct --
> especially when I send them to the Pd list!
>
>
> On 3/12/2015 1:58 PM, Charles Z Henry wrote:
>>
>> On Thu, Mar 12, 2015 at 3:18 PM, David Medine <dmedine at ucsd.edu> wrote:
>>>
>>> Yeah, of course. Block size 1 and high sampling rate will make the timing
>>> between control and audio super tight (ChucK does this, for example). It
>>> will also eat the hell out of your CPU. It's a trade off. This is because
>>> you start calling all the DSP functions once every 1/192k seconds instead
>>> of
>>> once every 1.45ms.
>>
>> This last sentence is also a misconception--the dsp tick function is
>> called every 64 samples, as commonly defined.
>>
>>      sys_time_per_dsp_tick = (TIMEUNITPERSECOND) *
>>          ((double)sys_schedblocksize) / sys_dacsr;
>>
>> sys_schedblocksize gets set from DEFDACBLKSIZE
>>
>> So, the dsp_tick gets called, and when there is a sub-patch with
>> [block~ 1], it loops over the graph generated from the sub-patch 64
>> times.
>>
>> You'd find this behavior coded with the block prologue and epilogue
>> functions.

_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150313/8cdc5318/attachment.html>