On 09/17/2015 11:55 PM, Roman Haefeli wrote:
One thing I'd like to know: Is there one graph for all patches in a certain instance of Pd?
yes
It seems that adding a tilde-object to a patch causes the DSP graph to be recalculated.
yes
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.
yes
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?
no (you're right)
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?
[skipping those]
Or is it even exponential? There is no way to partition the graph and update only one partition, is there?
no
[...]
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.
because the table-accessing objects will only check whether a table exists and of what size it is) when the DSP graph is re-calculated. this is a speed optimization, so those objects don't need to check the table existance/size in each signal block. the way how it is implemented is, that a table is marked as "being used in DSP processing" by a referencing object. as soon as such a table changes it's size (or is deleted), the DSP graph is notified - by means of recalculation.
i guess the API could be changed to *unuse* a table (a simple refcounter should do), so that as soon as no DSP-object is referencing the object within the DSP-graph, any substantial change to it wouldn't trigger a DSP graph recompilation.
gfmadsr IOhannes