[PD] maximum "control rate" in Pd

Charles Z Henry czhenry at gmail.com
Thu Mar 12 23:14:27 CET 2015


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.



More information about the Pd-list mailing list