<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-03-12 19:36 GMT-03:00 Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">since it was mentioned here, what's the behaviour and deal with [vnsapshot~]? Cause there's no help file for ir yet.</div></blockquote><div><br></div><div>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...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-12 19:14 GMT-03:00 Charles Z Henry <span dir="ltr"><<a href="mailto:czhenry@gmail.com" target="_blank">czhenry@gmail.com</a>></span>:<div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Mar 12, 2015 at 5:01 PM, David Medine <<a href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>> wrote:<br>
> @Charles: None of those five sentences is a misconception. When I said 'DSP<br>
> functions' I meant the functions of the form 'whatever_tilde_perform', not<br>
> the dsp tick function. I see how this might lead to a misunderstanding.<br>
<br>
</span>Sorry if I was unclear as well.  We *are* trying to split hairs here,<br>
of course, just to have an accurate description.<br>
<br>
It's not *all* of the dsp functions.  I thought this was unclear and<br>
tried to clarify: rather than scheduling them more often, it actually<br>
just loops over the sub-graphs multiple times when the block size is<br>
low.  There is always a parent function which is being run once every<br>
64 samples (the default).<br>
<span><br>
> Also, I see that suseconds_t (which is the type of now.tv_usec)  is an<br>
> integer, as I had previously thought, so I am really perplexed as to how<br>
> [delay] can apparently deliver bangs within less than 1us. I would love for<br>
> someone to explain this to me. It is a small detail and it doesn't really<br>
> matter in practice, but I am annoyed when my inferences are not correct --<br>
> especially when I send them to the Pd list!<br>
><br>
><br>
> On 3/12/2015 1:58 PM, Charles Z Henry wrote:<br>
>><br>
>> On Thu, Mar 12, 2015 at 3:18 PM, David Medine <<a href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>> wrote:<br>
>>><br>
>>> Yeah, of course. Block size 1 and high sampling rate will make the timing<br>
>>> between control and audio super tight (ChucK does this, for example). It<br>
>>> will also eat the hell out of your CPU. It's a trade off. This is because<br>
>>> you start calling all the DSP functions once every 1/192k seconds instead<br>
>>> of<br>
>>> once every 1.45ms.<br>
>><br>
>> This last sentence is also a misconception--the dsp tick function is<br>
>> called every 64 samples, as commonly defined.<br>
>><br>
>>      sys_time_per_dsp_tick = (TIMEUNITPERSECOND) *<br>
>>          ((double)sys_schedblocksize) / sys_dacsr;<br>
>><br>
>> sys_schedblocksize gets set from DEFDACBLKSIZE<br>
>><br>
>> So, the dsp_tick gets called, and when there is a sub-patch with<br>
>> [block~ 1], it loops over the graph generated from the sub-patch 64<br>
>> times.<br>
>><br>
>> You'd find this behavior coded with the block prologue and epilogue<br>
>> functions.<br>
<br>
</span><div><div>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div></div>