DAT FileOut cooks even when input is locked

General TouchDesigner Discussion
1

I have a few File Out DATs that don’t use expressions for parameters and whose inputs are locked. I think that means they should never cook. I also don’t think there are any scripts that are scripting the cooking of these dats. However, at the top of the performance monitor window, I see this:

0.076 ms     1 cook   /ui/dialogs/menu_op (COMP:container)
                   frame  Start Frame
    0.013 ms    81 cook  Forcing nodes to cook at start of frame
    0.000 ms       misc   DAT_FileOut /container1/presets/fileout_add (DAT:fileout)
    0.001 ms       cook    Propagating changes to other nodes /container1/presets/fileout_add (DAT:fileout)
    0.000 ms       misc   DAT_FileOut /container1/presets/fileout_none (DAT:fileout)
    0.000 ms       cook    Propagating changes to other nodes /container1/presets/fileout_none (DAT:fileout)
    0.000 ms       misc   DAT_FileOut /container1/presets/fileout_delete (DAT:fileout)
    0.001 ms       cook    Propagating changes to other nodes /container1/presets/fileout_delete (DAT:fileout)
    0.001 ms       misc   DAT_FileOut /container1/presets/fileout_rename (DAT:fileout)
    0.000 ms       cook    Propagating changes to other nodes /container1/presets/fileout_rename (DAT:fileout)
    0.001 ms       misc   DAT_FileOut /container1/presets/fileout_update (DAT:fileout)
    0.000 ms       cook    Propagating changes to other nodes /container1/presets/fileout_update (DAT:fileout)

More simply it’s

DAT_FileOut /container1/presets/fileout_add (DAT:fileout)

followed by

Propagating changes to other nodes /container1/presets/fileout_add (DAT:fileout)

several times.

Why are these DATs cooking? I’ve checked builds 61480 and 61100. Thanks for anyone’s insight.

2

woof…

That’s a weird one.

How often do you need to write to file? We usually use a table or text dat and the .save() method for calibration and the like.

3

I would save every couple of minutes. This is my own implementation of a presets container, and I have lots of bases that have presets, sometimes inside replicators. I’m seeing the issue in a simplified project with only one container, so I don’t think it’s due to other complexities.

Saving from a null table is a good fallback plan. Thanks for mentioning it.

Also I forgot to mention that there is a FileIn DAT in this project whose file in val is a constant, and it’s the same file as all of the file out dats. The file in DAT has refresh enabled. Even when the file in dat’s refresh is disabled, the file out dats still cook in performance monitor.

4

I tested in an empty project with only the fileout DAT and saw the same thing.

Repeated the test with the viewer off as well - same result.

Wish I had better news.