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

[IOhannes m zmölnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150920/2fbfb0c3/attachment.sig>