On 11/23/2015 07:56 PM, William Huston wrote:
>> what qualifies as a "complex orphaned network"?
[...]
>
> A tilde object is "active" (not orphaned) when its output is connected to
> any object which stores computed audio in memory, or sends audio
> external to PD,  like [dac~], [tabwrite~], or [writesf~].
>
> (OK-- externals become tricky, as PD's DSP compiler needs to understand
> wither the external object sends audio outside PD, such as across
> a network, or stores audio in memory)

(does [hip~] store audio in memory?)

how is Pd supposed to know "this"?

the problem with all this is, that the entire scheme for saving CPU
cycles will be screwed if you there is a single object in your
to-be-orphaned network of which you don't know whether it has
"side-effects" (as in I/O; but also any other side-effect) or not.

> A [throw~] / [catch~] network is orphaned if the output of [catch~]
> is connected to an orphaned tilde network.
>
> These kinds of orphans (at least for PD vanilla objects)
> should be easy to detect

since Pd allows an external to override built-in classes, you don't even
know whether a sole unconnected [osc~] object does not phone home.

(though you probably can still find out whether any given object is
constructed from an external or "built-in")

in any case, the suggestion boils down to maintaining a "whitelist" of
objects-without-sideeffects, which is fragile at best.

> I want to understand whether orphaned tilde objects are part of
> the DSP graph, and steal cycles? or are they harmless?

yes. no (not in your sense).

if you are concerened about orphaned objects stealing CPU cycles, delete
them from your patch. this way they are *guaranteed* to not take any CPU
(nor memory), even with the most naive scheduler.
also: Pd has [switch~] to turn off parts of a DSP-graph (even if it is
not orphaned!).

gfmadsr
IOhannes


_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list