Cookedthisframe not dependable

would like to set a COMP bg with an icon if the last operator in the chain isn’t cooking. looks like cookedthisframe is what i want, but as demonstrated in this tox by turning the nulls viewer on and off, it requires a bypass/refresh on the eval for the value to update

cookedthisframe.toe (3.6 KB)

1 Like

Can you use the expression op.cookedThisFrame or op.cookedPreviousFrame as a work around? In this particular cas the issue is that the Eval DAT cooked before the null TOP did in that frame, as op.cookedThisFrame does not request a cook from the node in question for obvious reasons.

op.cookedThisFrame is what i was using before, and cookedPreviousFrame doesn’t seem to be reliable either. Here is a more accurate depiction of what I’m trying to do, if you have a better suggestioncookedPreviousFrame.toe (6.8 KB)

Can you try this expression? I think you need both cookedThisFrame and cookedPreviousFrame for this to handle the case depending on whether base is cooked before or after null1 in the current frame.

op(’./out1’) if op(’./null1’).cookedPreviousFrame or op(’./null1’).cookedThisFrame else op(’./icon’)

Here it is with that expression. neither the expression updates correctly, nor the base opview.

One should see a change when flipping the switchTOP

cookedPreviousFrame and this frame.1.toe (6.9 KB)

So the problem with the setup in the last file is that even with switch1 pointing to transform1, out1 was in used by base1. so null1 is always getting cooked because it is getting requested by out1.

The attached file should be doing what you want, I changed things around so whether out1 cooks is independent of what icon is being show, and also had to use a switch TOP as the icon since we might have a bug where the viewer didn’t updated properly from expression. We may have some dependency issues with cookedThisFrame and cookedPreviousFrame not monitoring time dependencies (so wasn’t triggering updates due to time dependencies), so I’m comparing absTime.frame and cookAbsFrame. Theoretically abTime.frame & cookAbsFrame could be off by a realtime slice, but I’m not seeing it in the setup. Hope this helps and thanks for finding some bugs.

cookedFrame.toe (6.9 KB)

This almost works, but is probably more complicated then is worth it. I can still break it pretty easily by bypassing transform1 and toggling the switch. this will show the animation in the switch while the base1 viewer is frozen, and re-engaging the transform doesn’t fix this, base1 needs to be initialized via bypass or viewer toggle for the expected behavior to start working properly.

I’m gonna leave this be for now, but if anything with the cook dependencies or op viewer updates gets fixed, let me know, I’d like to revisit this technique

I think that issue is the same as needing to use cookPreviousFrame, depends on the cook order of the out TOP the condition is true for current or previous frame. We don’t have a deterministic cook order so likely no fixes coming for that. Adding a buffer for when the frame is would fix the toggle issue.

absTime.frame - 5 < op(‘out1’).cookAbsFrame

The op viewer update bug doesn’t affect what you want, other than using a condition to determine the op showing doesn’t seem to update all the time. But I’ll be taking a look at that.