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 )