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