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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
