<div dir="ltr">Got it. Thanks. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 23, 2015 at 2:47 PM, IOhannes m zmölnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/23/2015 07:56 PM, William Huston wrote:<br>
>> what qualifies as a "complex orphaned network"?<br>
</span>[...]<br>
<span class="">><br>
> A tilde object is "active" (not orphaned) when its output is connected to<br>
> any object which stores computed audio in memory, or sends audio<br>
> external to PD,  like [dac~], [tabwrite~], or [writesf~].<br>
><br>
> (OK-- externals become tricky, as PD's DSP compiler needs to understand<br>
> wither the external object sends audio outside PD, such as across<br>
> a network, or stores audio in memory)<br>
<br>
</span>(does [hip~] store audio in memory?)<br>
<br>
how is Pd supposed to know "this"?<br>
<br>
the problem with all this is, that the entire scheme for saving CPU<br>
cycles will be screwed if you there is a single object in your<br>
to-be-orphaned network of which you don't know whether it has<br>
"side-effects" (as in I/O; but also any other side-effect) or not.<br>
<span class=""><br>
> A [throw~] / [catch~] network is orphaned if the output of [catch~]<br>
> is connected to an orphaned tilde network.<br>
><br>
> These kinds of orphans (at least for PD vanilla objects)<br>
> should be easy to detect<br>
<br>
</span>since Pd allows an external to override built-in classes, you don't even<br>
know whether a sole unconnected [osc~] object does not phone home.<br>
<br>
(though you probably can still find out whether any given object is<br>
constructed from an external or "built-in")<br>
<br>
in any case, the suggestion boils down to maintaining a "whitelist" of<br>
objects-without-sideeffects, which is fragile at best.<br>
<span class=""><br>
> I want to understand whether orphaned tilde objects are part of<br>
> the DSP graph, and steal cycles? or are they harmless?<br>
<br>
</span>yes. no (not in your sense).<br>
<br>
if you are concerened about orphaned objects stealing CPU cycles, delete<br>
them from your patch. this way they are *guaranteed* to not take any CPU<br>
(nor memory), even with the most naive scheduler.<br>
also: Pd has [switch~] to turn off parts of a DSP-graph (even if it is<br>
not orphaned!).<br>
<br>
gfmadsr<br>
<span class="HOEnZb"><font color="#888888">IOhannes<br>
<br>
</font></span><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><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">--<br>
May you, and all beings<br>
be happy and free from suffering :)<br>
-- ancient Buddhist Prayer (Metta)<br></div></div></div></div>
</div>