[PD] [nbuntil]: an non-blocking [until] replacement

Jonathan Wilkes jancsika at yahoo.com
Mon Dec 17 18:53:00 CET 2012





----- Original Message -----
> From: Roman Haefeli <reduzent at gmail.com>
> To: pd-list at iem.at
> Cc: 
> Sent: Monday, December 17, 2012 3:07 AM
> Subject: Re: [PD] [nbuntil]: an non-blocking [until] replacement
> 
> On Sun, 2012-12-16 at 23:17 -0800, Jonathan Wilkes wrote:
>> 
>> 
>> 
>>  ----- Original Message -----
>>  > From: Simon Wise <simonzwise at gmail.com>
>>  > To: pd-list at iem.at
>>  > Cc: 
>>  > Sent: Sunday, December 16, 2012 7:58 PM
>>  > Subject: Re: [PD] [nbuntil]: an non-blocking [until] replacement
>>  > 
>>  > On 17/12/12 08:06, Jonathan Wilkes wrote:
>>  >>  Why not just trigger each iteration with [bang~]?
>>  > 
>>  > because with [bang~] you would get a single iteration per block, 
> rather than as 
>>  > many iterations as you have time for ... which seems to be the 
> intention of 
>>  > [nbuntil], and very useful where you might want to do a loop which may 
> be too 
>>  > long for one cycle but you can wait and use the results when they are 
> ready, 
>>  > after a few cycles perhaps.
>> 
>>  Ah I see.  So it assumes iterations won't take a majority of a dsp 
> tick.
> 
> No. Assume each iteration usually takes 5 ms under no load. If the CPU
> core the Pd thread is currently running on is under 50% load,  one
> iteration of the same task would use 10 ms. 
> (This purely hypothetical, I haven't thoroughly tested those cases yet).

What I mean is that if there's a dsp tick every 9ms and each iteration takes
5ms then you're still going to get dropouts because you've got time to start
two iterations but not enough time to finish them.

I may be misunderstanding scheduling, though.

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



More information about the Pd-list mailing list