I’m not sure if this would be considered a bug, optimization idea, a feature request, or if I’m just not getting something (highly possible).
I’m trying to optimize my large network. I’ve read loads of documentation and watched the 3 excellent TDSW videos on the topic.
In my networks I make heavy use of Base Comps with custom parameters. What I find troublesome is that anytime a comp’s parameters change, everything inside that comp referencing it will also cook… regardless of if it has no bearing on the final output or anything downstream. I’ve attached an example to illustrate this.
FX-Pipeline-Cook-Test.toe (6.3 KB)
I discovered a workaround by using a Parameter CHOP and passing that into a Switch before using any of the pars in my comp (b/c Switches seem to have this magical property of not cooking things when it’s flipped off). So I flip the switch based on some value/heuristic determining if my comp is active or not.
It seems liberal usage of custom comps & pars should be encouraged/optimized as it helps keep everything tidy and decoupled. And this workaround is quite tedious to implement/maintain in every single comp. I wonder if there is a more general solution to this problem?
Before I knew better I looked into disabling the Cook flag, but now I know this is a bad idea. So it seems like this is not really solvable in an elegant way via a user-built mechanisms, as we don’t have any way to fully disable/enable cooking of a portion of the network at runtime.
Perhaps TD could generally optimize for the case where no downstream effects are possible… which seems complex, but doable.
Or perhaps the Base Comp could come with an “Active” toggle (similar to Ops like Cache TOP). It’d be on by default, users can add custom expressions to enable/disable it. When it’s on everything functions as it does today, but when it’s off TD would know not to cook anything inside of the comp (or at least not cook anything based on the parameters). Essentially TD would do the same Switch optimization trick but every time a Comp parameter is evaluated based on this flag.
Thoughts? Other ideas?
Looking forward to your feedback.