Hi Katja
Thanks for your feedback.
On Mon, 2012-12-17 at 11:56 +0100, katja wrote:
Cool, with [nbuntil] the workload is even spread over the cores!
I don't think that [nbuntil] will help in making Pd use more than one core. Since [nbuntil] is just an abstraction, everything run "below" it is still part of the pd process/thread. For fully exploiting many cores, real threading is needed, I suppose.
So now you can do calculations on long arrays without fear of CPU spikes.
That is the idea.
And in turn, audio latency may be set to lower level.
To some degree, probably. There is a certain range for it to work best. If each iteration is too small/fast, the penalty added by [nbuntil] is too big and it will by itself cause drop-outs. OTOH, if a single iteration takes too much time, this will also cause a drop-out (i.e. if it takes longer than the currently configured audio buffer setting). As a rule of thumb, the optimal CPU time for a single iteration to consume is probably around <audio buffer setting>/2.
Regarding your calculations for long arrays and depending on the complexity of your calculations, it might be better to iterate with an outer [nbuntil] loop and an inner [until] loop in order to reach a sensible iteration time for [nbuntil].
Roman