[PD] maximum "control rate" in Pd

Fri Mar 13 08:51:52 CET 2015

>> I thought there was a limit control rate that was below
>> the audio rate, but curiously it can go over.
> That is what I'm trying to say since - I don't know - at
> least three posts.

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.

> [timer] shows the correct number. However, even that
> simple  patch clogs my CPU when setting it to 1e-06

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.

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.

*> But maybe the question is this: what is the *
*> smallest interval one can specify in Pd to *
*> reliably trigger messages through time?*

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.

But yeah, I think everyone gets the question anyway, but the final detailed
answer is still out there somewhere.

This is what I get so far, anyway: 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 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.

By making it more straightforward, it has no limits, it can go faster than
you'll ever need it to until it kills your CPU.

cheers

2015-03-12 23:47 GMT-03:00 Jonathan Wilkes <jancsika at yahoo.com>:

> 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/db1bd1bc/attachment-0001.html>