<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 5:55 PM, Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all<br>
<br>
First, I'm not even sure if 'DSP graph' is the correct term. Pd's<br>
documentation[1] states that all DSP objects are internally arranged<br>
into a linear order which I believe is often called 'DSP graph'. There<br>
are apparently some actions that cause this DSP graph to be rebuilt.<br>
Rebuilding takes time and is often the cause of audio drop-outs. I would<br>
like to have a better understanding of the mechanics going on behind the<br>
scenes with the hope to be able to optimize my Pd programming.<br>
<br>
One thing I'd like to know: Is there one graph for all patches in a<br>
certain instance of Pd? It seems that adding a tilde-object to a patch<br>
causes the DSP graph to be recalculated. Now, if _everything_ is in the<br>
same graph, this would mean the whole graph needs to be recalculated<br>
when adding objects (or abstractions containing tilde-objects, for that<br>
matter), no matter where I put them. It would make no difference whether<br>
I have one big patch with 1000 tilde-objects loaded or 100 smaller<br>
patches with 10 tilde-objects each, when adding new objects, would it?<br>
Is the time it takes to recalculate the graph only dependent on the<br>
number of tilde-objects running in the current instance of Pd? If so, is<br>
that a linear correlation? 10 times more tilde-objects means it takes 10<br>
times as long to recalculate the graph? Or is it even exponential? There<br>
is no way to partition the graph and update only one partition, is<br>
there?<br>
<br>
On a related note, I made the following observation and I'm wondering<br>
if/how that is related to the DSP graph: I create a minimalist patch<br>
with a small [table foo 100] and I measure the time it takes to 'resize'<br>
it to 99 with [realtime]. On my box, this takes 0.01 ms. I expected it<br>
to be fast, since memory access is very quick. Now, I additionally load<br>
a much more complex patch with many tilde-objects. I 'resize' the table<br>
again and it still takes only 0.01ms. Now I put a [tabread~ foo]<br>
somewhere in the patch. Now,'resize'-ing the table foo to 100 takes<br>
20ms. Even if I remove the [tabread~ foo] again, resizing the table<br>
still takes at least 20ms. There is no way to make it fast again except<br>
restarting Pd. I also figured out that when only a non-tilde [tabread<br>
foo] is refencing the table I'm resizing, the resizing keeps being fast.<br>
Only when tilde-objects are referencing the table, resizing that very<br>
table becomes slow. The actual time seems dependent on the complexity of<br>
the loaded patch(es). And it also corresponds with the time it takes to<br>
send 'dsp 1' to pd (when dsp is switched off).<br>
<br>
Why is resizing tables so much slower, when tilde-objects are<br>
referencing it? I noticed that even resizing very small tables can be a<br>
cause for audio drop-outs. I wonder whether 'live-resizing' should be<br>
avoided altogether.<br>
<br>
Yeah, that's a bunch of questions... Even when knowing the answer to<br>
only some them, it might clear things up quite a bit.<br>
<br>
Roman<br>
<br>
<br>
<br>
[1] "Pd sorts all the tilde objects into a linear order for<br>
running." ( <a href="http://msp.ucsd.edu/Pd_documentation/x2.htm#s4.2" rel="noreferrer" target="_blank">http://msp.ucsd.edu/Pd_documentation/x2.htm#s4.2</a> )<br>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>