cookOff: keep op chains from cooking & cache data

here’s my solution i made a week or two ago to keeping/stopping op chains from cooking when you really need them to cut it out, and optionally cache the data for the current session.

It will generally keep those notorious “always cooking” operators like render TOPs, trigger CHOPs from cooking upstream

this approach does NOT change lock, bypass, or cook flags.

probably makes sense to save these as separate TOX for each op family, and ultimately i think they make a good candidate for a bonafide operator in each family


cookOff.toe (7.37 KB)

ohhhhh!

I think your CHOP approach could also work with another constant CHOP feeding the second input - I often end up using than for creating snap channels - you have to turn of “Active Needs Current”, but it should work like a hold CHOP without cooking every frame.

That’s only if you’re interested in more “pure” TouchDesigner approach, otherwise I quite like your script CHOP trick here. Very nice!
base_constant_snap.tox (1.45 KB)

The reason why I didn’t use the Constant CHOP’s snap feature is because it doesn’t cache data from multiple sample CHOPs, only single sample CHOPs. It also won’t store more than 40 channels from even a single sample CHOP.

I tested various types and sizes of input data for each operator family and found a solution that works for all input types, just like a real operator in that OP family would (generally) allow for.

But really this is just a proof of concept, it’s not meant to be the definitive solution to this problem. Derivative just needs to implement an operator like this for each family, so people can stop writing hacky scripts and/or messing with various OP flags when all we really need is a simple, unified approach to control cook flow, and optionally cache the data.

Good point! Well thought out sir, and an excellent RFE.

+1

Also, edorgeville (via the slack chat server) mentioned external persistent storage which is important to mention. This approach only caches data for the current session, but my approach could be modified with a python save method to optionally save the cache data in a TouchDesigner native file format, saved separately from the TOE or TOX. And allows for these to be managed as assets in a Github repo.

This in contrast to the practice of setting the lock flag. For those that aren’t aware, Locking is generally frowned upon as unless it’s an extremely small amount of data, it bloats the TOE or TOX, even causing a drop in frames when you save your TOE/TOX as the total data from locked TOPs can’t write to disk in time for the next frame. I actually inherited a project in recent memory that has over 100MB in locked OPs and every time you try to save, it would make TouchDesigner hang for 3+ seconds.

Great COMPs!!! Thank you!