----- Original Message -----
> From: Roman Haefeli <reduz...@gmail.com>
> To: pd-list@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 <simonzw...@gmail.com>
>> > To: pd-list@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@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
