turning off evaluation for a sub patch is really nice. however, setting Evaluate to 0 keeps the last frame in the Renderer. is this a bug or intended to work like this? if not a bug: is it possible to disable evaluation from inside a patch?
(right now, one has to disable the Layer of a sub patch one frame before disabling evaluation if there should be no freeze frame; would be great if the root patch wouldn’t have all the Framedelay clutter for that)

(oh, and wouldn’t it be nice if the default visibility for the Evaluate pin wouldn’t be hidden but invisible?)

you can connect the subpatch to a group node outside the subpatch and disable this group together with the evaluate pin. thats how i do it right now. not very elegant, i agree.

i currently would do it like u7angel. i will note the feature request for being able to disable rendering more easily. however since this is no bug i will flag u7angels post as the solution.

interesting. never thought of Group. when setting the evaluate-Toggle to 0, i always connected it to a TogEdge, from which i used the downedge which went into a FrameDelay and then in the OR along with the Toggle. the other solution could save me two nodes :)

hm, i switched the layer instead of the group thingy… perhaps we should make a comparison of the possibilities to find the fastest and most stable way.

btw - stable:
usually unevaluated subpatches seem stable, but i had it one time in a huge patch, that an unevaluated subpatch caused a memoryleak. so i needed to “disable” it the old way to keep the whole system stable. sorry but the whole patch is too huge and won’t run on any system, so i can’t provide a reproducible patch, but perhaps others stumbled upon similar probs, too?

I think it’s really necessary that disabled patches keep their output pin values and content. It is a S+H for Layer information which is really powerful and saves a lot of resources, if the layer doesn’t change.

the problem with disabling evaluete on patch connected to the group that it gonna request renderer context on unevaluated connectin causing pipeline errors and other nasty stuff, so using u7angels tip has critical importantce for stability reasons in meantime…

I agree.

A problem i Got a lot of times is that, on opening, all patches must be evaluate on at least one time for everything to work correctly.

we also use a workaround in this case called init value, with just a bang sended on first frame on evaluration pins.
the problem with start up colud be sorted with kinda console command or crack option to evaluate everything on first frame