I have a rather large patch for an installation that will be going up soon, and I think somewhere down the line with all the complexity that’s going on and Touchdesigners clever internal memory/resource management, I am noticing some of the sliders that are controlling switches, including crossfading switches through different effects are starting to have a behavior where the first time that slider is moved and a new channel of the switch gets activated, the rendering stalls for a few seconds.
Is there any way for me to manually mitigate this? I would rather that those upstream nodes were buffered upfront when the patch is loaded so that things don’t stall in the middle of a slider motion.
It does, my recommendation with out knowing the specifics is to use something like a constant chop with default channels name and value, then pass that into the first input of a replace chop, and put the ui slider chop into the second input.
This will essentially initialize the network with these values with out having to do a bunch of python hacks to force cook sliders etc.
And if you want to go the python way and force everything to cook/load at least once, refer to the OP Class and use the cook method with force and recurse on. op.cook(force=True, recurse=True)
I am using a preset manager system from Alphamoonbase.berlin to save and recall all of the settings, I am wondering if this suggestion would complicate that?
and I am wondering if this would actually do what I am going for, for example, one of the sliders controls switching through several different 3D models. on first load if i move that slider it hangs for maybe a few seconds, and this happens with several of the sliders that are connected to switches, but after they are all moved their full range activating all of the options, they no longer have any hangups.
I guess I am wondering how this suggested solution would change that? if it is a renamed constant chop, how would that activate all of those switched networks to cook upon loading the patch? Since there are several different things going into the switches and some even have the crossfade on.
this seems more like what I was expecting. I haven’t done a ton of python in TD, where would I put this? next to each problematic switch in an execute chop that triggers on the patch load or start or something?
cook(force=False, recurse=False)→ None:
Cook the contents of the operator if required.
force - (Keyword, Optional) If True, the operator will always cook, even if it wouldn’t under normal circumstances.
recurse - (Keyword, Optional) If True, all children and sub-children of the operator will be cooked.
You can try using the performance monitor and set a larger ms count at bottom to catch the heavy frame when it happens and see what is taking a long time to cook. Have you tried this yet?
Sure, I can try that, though it seems fairly intuitive that the thing all of the stalls have in common is that they occur when adjusting one of the sliders that controls one of these switches, and then the stall stops happening after sliding the full range of that slider up and down.
but so far the python command and reloading the patch doesn’t seem to have any effect. I am guessing I may be doing something incorrectly.
these scenes are loaded using the scene loader patch, not sure if that affects anything?
You are running the recursive cook command on a switch TOP which has no children to recurse into. Try running it in some top level node
op(„yourTopLevelCOMP“).cook(force=True, recurse=True)
Ok, I’ll try that. I had thought that the upstream connections of the switch would be affected. Hopefully, I can get this to work with the scene loader, as having everything in the entire patch with all of the scenes cooking continually would be wayyyy too much (like 12 different complex patches resulting in 4k output). Will give it a shot and see what happens. Thank you
