[PD] Understanding the mechanics of rebuilding Pd's DSP graph

[Matt Barber]

One more thing to think about is how the DSP graph is handled using dynamic
patching. For a long time there was a "bug" where the last audio object
added didn't trigger a recalculation and would be left out of the DSP graph
until the next edit. Is this still the case? The workaround, if I remember
correctly, was to add one last dummy object at the end of dynamic patching.

Matt

On Thu, Sep 17, 2015 at 5:55 PM, Roman Haefeli <reduzent at gmail.com> wrote:

> Hi all
>
> First, I'm not even sure if 'DSP graph' is the correct term. Pd's
> documentation[1] states that all DSP objects are internally arranged
> into a linear order which I believe is often called 'DSP graph'. There
> are apparently some actions that cause this DSP graph to be rebuilt.
> Rebuilding takes time and is often the cause of audio drop-outs. I would
> like to have a better understanding of the mechanics going on behind the
> scenes with the hope to be able to optimize my Pd programming.
>
> One thing I'd like to know: Is there one graph for all patches in a
> certain instance of Pd? It seems that adding a tilde-object to a patch
> causes the DSP graph to be recalculated. Now, if _everything_ is in the
> same graph, this would mean the whole graph needs to be recalculated
> when adding objects (or abstractions containing tilde-objects, for that
> matter), no matter where I put them. It would make no difference whether
> I have one big patch with 1000 tilde-objects loaded or 100 smaller
> patches with 10 tilde-objects each, when adding new objects, would it?
> Is the time it takes to recalculate the graph only dependent on the
> number of tilde-objects running in the current instance of Pd? If so, is
> that a linear correlation? 10 times more tilde-objects means it takes 10
> times as long to recalculate the graph? Or is it even exponential? There
> is no way to partition the graph and update only one partition, is
> there?
>
> On a related note, I made the following observation and I'm wondering
> if/how that is related to the DSP graph: I create a minimalist patch
> with a small [table foo 100] and I measure the time it takes to 'resize'
> it to 99 with [realtime]. On my box, this takes 0.01 ms. I expected it
> to be fast, since memory access is very quick. Now, I additionally load
> a much more complex patch with many tilde-objects. I 'resize' the table
> again and it still takes only 0.01ms. Now I put a [tabread~ foo]
> somewhere in the patch. Now,'resize'-ing the table foo to 100 takes
> 20ms. Even if I remove the [tabread~ foo] again, resizing the table
> still takes at least 20ms. There is no way to make it fast again except
> restarting Pd. I also figured out that when only a non-tilde [tabread
> foo] is refencing the table I'm resizing, the resizing keeps being fast.
> Only when tilde-objects are referencing the table, resizing that very
> table becomes slow. The actual time seems dependent on the complexity of
> the loaded patch(es). And it also corresponds with the time it takes to
> send 'dsp 1' to pd (when dsp is switched off).
>
> Why is resizing tables so much slower, when tilde-objects are
> referencing it? I noticed that even resizing very small tables can be a
> cause for audio drop-outs. I wonder whether 'live-resizing' should be
> avoided altogether.
>
> Yeah, that's a bunch of questions... Even when knowing the answer to
> only some them, it might clear things up quite a bit.
>
> Roman
>
>
>
> [1] "Pd sorts all the tilde objects into a linear order for
> running." ( http://msp.ucsd.edu/Pd_documentation/x2.htm#s4.2 )
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150919/b62f9cc4/attachment.html>