<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1442716673360_6478">Matt-- I don't believe that bug has been fixed.</div><div id="yui_3_16_0_1_1442716673360_6266"><br></div><div id="yui_3_16_0_1_1442716673360_6477" dir="ltr">Roman-- I haven't looked closely at the relevant code, but it looks like Pd recalculates the graph-- a single graph for the running</div><div id="yui_3_16_0_1_1442716673360_6334" dir="ltr">instance of Pd-- every time you add/remove a tilde object. (Not sure about</div><div id="yui_3_16_0_1_1442716673360_6399" dir="ltr">control objects, but it's easy to test.)</div><div id="yui_3_16_0_1_1442716673360_6400" dir="ltr"><br></div><div id="yui_3_16_0_1_1442716673360_6401" dir="ltr">The reason I'm comfortable speculating about this is the existence of</div><div id="yui_3_16_0_1_1442716673360_6437" dir="ltr">wireless tilde objects like [throw~] and [catch~] which use global</div><div id="yui_3_16_0_1_1442716673360_6523" dir="ltr">receiver names. When you change an object inside a tiny patch with</div><div id="yui_3_16_0_1_1442716673360_6529" dir="ltr">100 other patches open in the same Pd instance, how would Pd know that</div><div id="yui_3_16_0_1_1442716673360_6729" dir="ltr">you aren't altering a [throw~] which has a [catch~] in one of the 100 other</div><div id="yui_3_16_0_1_1442716673360_6730" dir="ltr">patches? Same for [send~]/[receive~], [delwrite~]/[delread~]/[vd~],</div><div id="yui_3_16_0_1_1442716673360_6776" dir="ltr">[table]/[tab*~], etc.</div><div id="yui_3_16_0_1_1442716673360_6778" dir="ltr"><br></div><div id="yui_3_16_0_1_1442716673360_12499" dir="ltr">Here's the dsp_tick routine in d_ugen.c:<br></div><div id="yui_3_16_0_1_1442716673360_12498" dir="ltr"><br></div><div id="yui_3_16_0_1_1442716673360_8530" dir="ltr">void dsp_tick(void)<br>{<br> if (dsp_chain)<br> {<br> t_int *ip;<br> for (ip = dsp_chain; ip; ) ip = (*(t_perfroutine)(*ip))(ip);<br> dsp_phase++;<br> }<br>}<br></div><div id="yui_3_16_0_1_1442716673360_8551" dir="ltr"><br></div><div id="yui_3_16_0_1_1442716673360_8550" dir="ltr">That is-- execute each dsp routine in the global array of dsp routines until</div><div id="yui_3_16_0_1_1442716673360_10697" dir="ltr">there are no more dsp routines to execute.</div><div id="yui_3_16_0_1_1442716673360_10698" dir="ltr"><br></div><div id="yui_3_16_0_1_1442716673360_12385">But this makes me wonder-- how does Supercollider "do its thing"? Seems like</div><div id="yui_3_16_0_1_1442716673360_12386" dir="ltr">it has an interface to add/remove parts of its dsp graph, and it can do so in a <br></div><div id="yui_3_16_0_1_1442716673360_12668" dir="ltr">much more efficient manner.</div><div id="yui_3_16_0_1_1442716673360_12387" dir="ltr"><br></div><div id="yui_3_16_0_1_1442716673360_12388" dir="ltr">-Jonathan<br></div><br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font face="Arial" size="2"> On Saturday, September 19, 2015 10:56 PM, Matt Barber <brbrofsvl@gmail.com> wrote:<br> </font> </div> <br><br> <div class="y_msg_container"><div id="yiv5176327649"><div><div dir="ltr"><div class="yiv5176327649gmail_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="yiv5176327649gmail_default" style="font-family:verdana, sans-serif;"><br clear="none"></div><div class="yiv5176327649gmail_default" style="font-family:verdana, sans-serif;">Matt</div></div><div class="yiv5176327649gmail_extra"><br clear="none"><div class="yiv5176327649yqt6175547255" id="yiv5176327649yqtfd32568"><div class="yiv5176327649gmail_quote">On Thu, Sep 17, 2015 at 5:55 PM, Roman Haefeli <span dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:reduzent@gmail.com" target="_blank" href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>></span> wrote:<br clear="none"><blockquote class="yiv5176327649gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi all<br clear="none">
<br clear="none">
First, I'm not even sure if 'DSP graph' is the correct term. Pd's<br clear="none">
documentation[1] states that all DSP objects are internally arranged<br clear="none">
into a linear order which I believe is often called 'DSP graph'. There<br clear="none">
are apparently some actions that cause this DSP graph to be rebuilt.<br clear="none">
Rebuilding takes time and is often the cause of audio drop-outs. I would<br clear="none">
like to have a better understanding of the mechanics going on behind the<br clear="none">
scenes with the hope to be able to optimize my Pd programming.<br clear="none">
<br clear="none">
One thing I'd like to know: Is there one graph for all patches in a<br clear="none">
certain instance of Pd? It seems that adding a tilde-object to a patch<br clear="none">
causes the DSP graph to be recalculated. Now, if _everything_ is in the<br clear="none">
same graph, this would mean the whole graph needs to be recalculated<br clear="none">
when adding objects (or abstractions containing tilde-objects, for that<br clear="none">
matter), no matter where I put them. It would make no difference whether<br clear="none">
I have one big patch with 1000 tilde-objects loaded or 100 smaller<br clear="none">
patches with 10 tilde-objects each, when adding new objects, would it?<br clear="none">
Is the time it takes to recalculate the graph only dependent on the<br clear="none">
number of tilde-objects running in the current instance of Pd? If so, is<br clear="none">
that a linear correlation? 10 times more tilde-objects means it takes 10<br clear="none">
times as long to recalculate the graph? Or is it even exponential? There<br clear="none">
is no way to partition the graph and update only one partition, is<br clear="none">
there?<br clear="none">
<br clear="none">
On a related note, I made the following observation and I'm wondering<br clear="none">
if/how that is related to the DSP graph: I create a minimalist patch<br clear="none">
with a small [table foo 100] and I measure the time it takes to 'resize'<br clear="none">
it to 99 with [realtime]. On my box, this takes 0.01 ms. I expected it<br clear="none">
to be fast, since memory access is very quick. Now, I additionally load<br clear="none">
a much more complex patch with many tilde-objects. I 'resize' the table<br clear="none">
again and it still takes only 0.01ms. Now I put a [tabread~ foo]<br clear="none">
somewhere in the patch. Now,'resize'-ing the table foo to 100 takes<br clear="none">
20ms. Even if I remove the [tabread~ foo] again, resizing the table<br clear="none">
still takes at least 20ms. There is no way to make it fast again except<br clear="none">
restarting Pd. I also figured out that when only a non-tilde [tabread<br clear="none">
foo] is refencing the table I'm resizing, the resizing keeps being fast.<br clear="none">
Only when tilde-objects are referencing the table, resizing that very<br clear="none">
table becomes slow. The actual time seems dependent on the complexity of<br clear="none">
the loaded patch(es). And it also corresponds with the time it takes to<br clear="none">
send 'dsp 1' to pd (when dsp is switched off).<br clear="none">
<br clear="none">
Why is resizing tables so much slower, when tilde-objects are<br clear="none">
referencing it? I noticed that even resizing very small tables can be a<br clear="none">
cause for audio drop-outs. I wonder whether 'live-resizing' should be<br clear="none">
avoided altogether.<br clear="none">
<br clear="none">
Yeah, that's a bunch of questions... Even when knowing the answer to<br clear="none">
only some them, it might clear things up quite a bit.<br clear="none">
<br clear="none">
Roman<br clear="none">
<br clear="none">
<br clear="none">
<br clear="none">
[1] "Pd sorts all the tilde objects into a linear order for<br clear="none">
running." ( <a rel="nofollow" shape="rect" target="_blank" href="http://msp.ucsd.edu/Pd_documentation/x2.htm#s4.2">http://msp.ucsd.edu/Pd_documentation/x2.htm#s4.2</a> )<br clear="none">
<br clear="none">_______________________________________________<br clear="none">
<a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
<br clear="none"></blockquote></div><br clear="none"></div></div></div></div><br><div class="yqt6175547255" id="yqtfd44609">_______________________________________________<br clear="none"><a shape="rect" ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>