----- Original Message -----
From: Roman Haefeli reduzent@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 simonzwise@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