<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Things are a lot more encapsulated in SuperCollider, and it can afford to be more efficient because 1) the DSP flow doesn't need to be in a strict correspondence with what appears in a GUI graph, 2) the user is not responsible for the DSP flow unless they want to be and do it on purpose with head/tail instantiation or node numbering, and 3) there are only a few ways of passing information between ugens: directly as arguments to another ugen, variables, and buses. Data in an SC Synth is more protected from the outside than anything in Pd is (as abstractions in Pd are still in the global space despite the dollarsign locality tricks), and the bus system controls I/O to and from Synths much more strictly. Pd doesn't enforce any of that because of its pledge to keep things global; this makes it extremely flexible, but at the price of a potentially more convoluted DSP graph.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">What would be interesting to know is whether there are best practices for patching that would help out the ugen graph routine.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 20, 2015 at 12:30 AM, Jonathan Wilkes <span dir="ltr"><<a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div>Matt-- I don't believe that bug has been fixed.</div><div><br></div><div 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 dir="ltr">instance of Pd-- every time you add/remove a tilde object.  (Not sure about</div><div dir="ltr">control objects, but it's easy to test.)</div><div dir="ltr"><br></div><div dir="ltr">The reason I'm comfortable speculating about this is the existence of</div><div dir="ltr">wireless tilde objects like [throw~] and [catch~] which use global</div><div dir="ltr">receiver names.  When you change an object inside a tiny patch with</div><div dir="ltr">100 other patches open in the same Pd instance, how would Pd know that</div><div dir="ltr">you aren't altering a [throw~] which has a [catch~] in one of the 100 other</div><div dir="ltr">patches?  Same for [send~]/[receive~], [delwrite~]/[delread~]/[vd~],</div><div dir="ltr">[table]/[tab*~], etc.</div><div dir="ltr"><br></div><div dir="ltr">Here's the dsp_tick routine in d_ugen.c:<br></div><div dir="ltr"><br></div><div 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 dir="ltr"><br></div><div dir="ltr">That is-- execute each dsp routine in the global array of dsp routines until</div><div dir="ltr">there are no more dsp routines to execute.</div><div dir="ltr"><br></div><div>But this makes me wonder-- how does Supercollider "do its thing"?  Seems like</div><div dir="ltr">it has an interface to add/remove parts of its dsp graph, and it can do so in a <br></div><div dir="ltr">much more efficient manner.</div><span class="HOEnZb"><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">-Jonathan<br></div></font></span><div><div class="h5"><br><div><br><br></div><div style="display:block"> <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 <<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>> wrote:<br> </font> </div>  <br><br> <div><div><div><div dir="ltr"><div 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 style="font-family:verdana,sans-serif"><br clear="none"></div><div style="font-family:verdana,sans-serif">Matt</div></div><div><br clear="none"><div><div>On Thu, Sep 17, 2015 at 5:55 PM, Roman Haefeli <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span> wrote:<br clear="none"><blockquote 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" href="http://msp.ucsd.edu/Pd_documentation/x2.htm#s4.2" target="_blank">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" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">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>_______________________________________________<br clear="none"><a shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">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></div></div></div></blockquote></div><br></div>