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

katja katjavetter at gmail.com
Mon Dec 17 11:56:50 CET 2012


Cool, with [nbuntil] the workload is even spread over the cores! So
now you can do calculations on long arrays without fear of CPU spikes.
And in turn, audio latency may be set to lower level. Great solution
Roman, thanks for sharing.

Katja


On Sun, Dec 16, 2012 at 10:51 PM, Roman Haefeli <reduzent at gmail.com> wrote:
> Hi all
>
> Audio drop-outs happen, when Pd needs more time to do something than is
> available (i.e. the configured audio buffer size). The underlying
> reasons are manifold, often it is because something requiring lots of
> CPU power is processed in zero logical time. For such of those problems,
> that can be divided into smaller tasks or those that already are of an
> iterative nature, [nbuntil] may provide a solution to avoid audio
> drop-outs.
>
> [nbuntil] works similar to the regular [until], but unlike the original,
> it breaks Pd's principle of "depth first". It measures how much time
> each iteration requires and delays the next iteration by this time. By
> employing [nbuntil], many kinds of tasks can be performed without
> causing drop-outs, that would otherwise block Pd for a certain amount of
> time.
>
> Example applications include loading presets or dynamic creation of
> parts "in the background". Yet, I use it to pre-calculate a set of
> tables while audio is running. I could imagine using it to create an
> emulation of a threaded [soundfiler], though a proof of concept is yet
> lacking and needs to be created. Contrary to Miller's suggestion of
> using a [readsf~] in an upsampled subpatch, [nbuntil]'s adaptive
> approach uses the maximum available CPU power.
>
> I'm curios to see whether other people find it useful and even find use
> cases I haven't thought of yet. Despite its rather simple design, I
> can't remember having seen this approach discussed here on the list. I'd
> also be interested if similar or different approaches have been used,
> but not yet discussed here.
>
> I'm currently not in the urgent need of a vanilla pseudo-threaded
> [soundfiler], but if there is enough interest, I'd be happy to dedicate
> some time to it (not totally sure, that it would work, 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