>> 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@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@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@gmail.com>:
On Thu, Mar 12, 2015 at 5:01 PM, David Medine <dmedine@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@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


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