A few big variable bug fixes are coming, feedback?

General TouchDesigner Discussion
1

I just wanted to give everyone a head’s up that we found a few bugs with variable evaluation that we are thinking of fixing, but they are pretty big changes so if anyone is expecting the ‘bugged’ behavior for their files to work, let us know (and we can figure out a solution). TUIK uses this bugged behavior a lot, but we are fixing it. Files should upgrade fine as long as any TUIK COMPS you use are still clones.

  1. If you use a variable in a COMP’s parameters, it would first search it’s component variables (inside itself) for variables, then search up. This is inconsistent because any other OP sitting right next to that COMP doesn’t follow the same search path, they would just search the COMP they are sitting in, and up. So for example
cvar -p /project1/mycomponent PATH = "mypath"
rvar PATH = "myrootpath"

If you use $PATH in the parameters of mycomponent, it used to return mypath, but in future builds it will return myrootpath. Nodes inside mycomponent would (and will) evaluate $PATH to mypath though.

The same is true for Path Variables.

If you want to use variables inside a COMP, you can use

var(".", "PATH")
  1. expressions used to evaluate component/root variables before script variables. So if you had
set PATH = "mypath"

in a script but PATH was also defined somewhere as a component/root variable (higher in the node tree), it would return the component/root variable. Commands such as

echo $PATH

would have returned the script variable (“mypath” in this example).
This is obviously inconsistent so we want to make it return the script variable, if available.
This was similarly true for node specific variables such as $TX in the Point SOP. It would have ignored the node specific $TX if it was defined as a Component/Root variable.

  1. We are adding better dependencies for component/root variables so nodes will recook when variables change/come into existence.

Will these changes (1 and 2 mostly) have a big impact on anyone?

2

hmm, I have a bunch of files that will likely break, often with TUIK based UIs that are no clones. But also other setups with lots of variables… So I’d definately appreciate a solution that keeps old files working.

nice! While you’re at this, I’d be really nice to be able to evaluate variables without lossing the “per variable cooking” feature (i.e. being able to prepend an evaluate DAT to local/variables without having each variable change trigger a cook on all nodes using any of the variables)

3

Do your TUIK files still use the DAT to export to their parameters at the top level? They would be Select DATs that grab tables from inside /ui/lib/TUIK2/color/expression. If so then we are changing those tables (in /ui) so the new expression that are getting exported will work still.

The per-cell dependency isn’t exactly a ‘while I’m at it’ type thing :slight_smile:. I did however added support for cell-dependency to the Evaluate and Select DAT last week, it will work for both variables and tab() expressions. Also tabnr and tabnc expressions will only cause cooks if the table size changed.