[PD] maximum "control rate" in Pd

[Alexandre Torres Porres]

2015-03-12 19:36 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> since it was mentioned here, what's the behaviour and deal with
> [vnsapshot~]? Cause there's no help file for ir yet.
>

Made a few tests and saw how snapshot~ only outputs the last saple from an
audio block, and also how vsnapshot~ can output each audio sample...



> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150314/9277568a/attachment.html>