Cloned C++ TOP reads its custom parameters as 0 after the clone master's allowCooking is turned off and on

Bugs
1

Title: Cloned C++ TOP reads its custom parameters as 0 after the clone master’s allowCooking is turned off and on

Build: TouchDesigner 2025.33230, Windows 11, NVIDIA RTX 5000 Ada (driver 32.0.15.9597)

Summary

Turning a clone master COMP’s allowCooking off and back on breaks every C++ operator inside its clones, permanently.

  • From then on, the clone’s plugin gets 0 for every numeric custom parameter from OP_Inputs (getParDouble, getParInt).
  • getParFilePath returns an empty string.
  • Python still shows the correct values on the clone (par.X.eval()).
  • No error or warning is shown.

It reproduces with the stock CPUMemoryTOP sample in a plain CPlusPlus TOP, and with a Custom OP loaded from the Plugins folder.

Steps to reproduce

  1. Build Samples/CPlusPlus/CPUMemoryTOP (Release x64).
  2. Make a Base COMP master holding a CPlusPlus TOP cpumem that loads the DLL. Set Brightness 0.8 and Speed 2.
  3. Copy master to clone1. Set its Clone parameter to master and turn on Enable Cloning.
  4. Add an Info CHOP on clone1/cpumem and watch the step channel.
  5. Run op('master').allowCooking = False, then op('master').allowCooking = True.

The attached .tox has this network ready. Set its Plugin DLL parameter to your CPUMemoryTOP.dll, then right-click run_repro → Run Script. It sets the values, toggles the master and prints the before/after values in the Textport.

Expected

clone1/cpumem keeps working: Brightness 0.8, Speed 2.

Actual

clone1/cpumem goes black and its animation stops. Brightness and Speed reach the plugin as 0:

before  clone1: step/frame 0.200  mean rgb 0.544  (Python: Brightness 0.80, Speed 2.00)
after   clone1: step/frame 0.000  mean rgb 0.000  (Python: Brightness 0.80, Speed 2.00)

The master is unaffected. It stays broken until the clone is re-cloned.

What I narrowed down

  • Only the master’s toggle triggers it. Turning allowCooking off and on for the clone itself is fine, and so are normal parameter edits on the master, which sync to the clone correctly.
  • Native operators are unaffected. A Constant TOP in the same clone keeps its colour.
  • It happens every time. After recovering, toggling the master again breaks the clone again.
  • Custom OP findings: in our own Custom OP (a Rive player), we logged what the plugin receives after the break.
    • getParInt and getParDouble return 0 for every custom parameter.
    • getParFilePath on a File parameter returns "" although the file exists.
    • getParString still returns the correct strings.
  • These don’t recover it: turning on the clone’s cloneImmune, pulsing the plugin’s own reload, changing the master’s parameters, or toggling allowCooking again.
  • These do recover it: turning the clone’s Enable Cloning off and on, or clearing and re-setting its Clone parameter. Both re-create the clone’s children (new op ids). Restarting TouchDesigner also recovers it.
  • Separately, allowCooking off drops the texture: while allowCooking is off, a TOP’s texture is dropped (reads 128x128). A plugin that skips its upload on the next cook, because nothing changed, then shows TD’s default texture. It isn’t a bug in itself, but worth knowing for anyone holding the last frame between cooks.

Attachment

clone_allowcooking_repro.tox (1.2 KB)

clone_allowcooking_repro.tox contains:

  • master and clone1, each holding a CPlusPlus TOP cpumem. Both load the DLL named in the COMP’s Plugin DLL parameter.
  • info_clone, an Info CHOP on the clone.
  • run_repro, the Text DAT that runs the test.

To recover clone1 afterwards, turn its Enable Cloning off and on.

3

hey @cem_futuretense ,
Thanks for reporting the issue and the clear repro instructions. I’m able to reproduce and we are having a look.
Varad

5

Thanks Varad,

Yes it’s very odd. The source of this bug is me working on the TDRive github repository by medcelerate, I was using this inside of a cloned comp which wrapped the custom TOP with helpers and noticed that custom c++ menus were not being populated inside of clones, and it spawned this dig into actually children of clones were never rebuilding or receiving their parameters.

I boiled it down to this test case instead of leaving it to an implementation question.