RESOLVED: 2025.32820 lfoCHOP cooking

[letsius]

Hi,
2025.32820
A standalone lfoCHOP with par.play = False should not cook.

Cheers,
Alex

[varad]

Hey @letsius ,

Thanks for the report. We are looking into the issue.

Varad

[rob]

After looking into it, not sure it should stop cooking.
It’s a timesliced CHOP so its continuously outputting values. (like a muted microphone for example).
If you’re looking to stop the cooking of the network entirely could you use other means?

[letsius]

Thank you,
Yes, that makes sense.

Actually, this question came up for a different reason. I had simply misinterpreted the bug.

lfoCooking.toe (205.5 KB)

But here’s an example: a Container COMP and a Base COMP, both COMPs hidden — inside each there’s a Container COMP with an LFO → comp.par.bgalpha.

In the probe you can see that inside both it’s silent.

But if I MMB-hold on the Container — then everything inside starts cooking.
MMB-hold on the Base — everything’s fine.

Apparently the artifact is related to this bug:

FIXED: TD parameters (or something else) optimaztion issue

Hi, Finally managed to localize this one properly — 2025.32820 Win. Root cause: TD re-validates all expressions/binds inside a non-cooking panel sub-network on every parent-parameter change, even though nothing there cooks or renders (even inside .allowCooking = False subtree). Needs all three: (1) a root COMP’s pars change every frame, (2) something inside listens to them (e.g. a Parameter CHOP), (3) there are expressions/binds in non-cooking panel COMPs anywhere inside (baseCOMP / regular op…

Cheers,
Alex

[rob]

Hi. We had a look at lfoCooking, and the reason the left MMB info causes it to cook is because the info does include some panel information, which the LFO is feeding into.
The base on the right doesn’t have the panel, so that LFO goes uncooked.
We’re still working on the TD parm optimization issue though.
Cheers