More local variables stuff (selectDAT)

It’s great to be able to use a select DAT for the local variables. I can define a component’s UI in a big table (it has 1 col per gadget) , and then, in each UI gadget’s local container, I select DAT one col from the master table and have all the properties available as variables. Working great!

Could you please keep this workflow in mind when finalizing the “local/*” design? i.e. if possible do not forbid a variables op of type DAT:select . Thanks.

And in case the variables DAT is a select DAT, it would be really great if the set command would then use the table the select DAT selects from to actually set the variable.

Cheers
Achim

We changed the design of the local/variables a bit. Its now a Table DAT called ‘setenv_variables’ which is piped into a Null DAT named ‘variables’.

The setenv command will changes entries in the setenv_variables Table.
So now you can use a Select and Merge DAT, piped into the Null DAT to do what you want.

neat, hope the new build will be available soon

So this means we can safely mess around inside local container? No restrictions?

Well, we haven’t decided on the names of every node and every feature that is going into this COMP. So it’s possible that you’d create a node thats ends up with a reserved name. If you leave every node you create with default names (select1, constant1) you should be ok.
It’s also likely that the name of ‘local’ will change, (we’d rename everyone’s automatically). So don’t make references to nodes inside it yet either.

Thanks Malcolm,

a shorter name for ‘setenv_variables’ table DAT would be nice (maybe just CVAR)

Any idea when the names for local/* will be finalized?

I’m asking cause I allready have adopted all my scripts/components to target local/*, so if possibe, I’d like to to this only one more time. I mean, if in the new build I have to change everything to use ‘local/setenv_variables’ and in the next build it will become ‘admin/setenv_variables’, I’d have to go over all scripts again. If you have any idea when, please let me know, so I can plan a little better.

Thanks again !

Ya, setenv_variables will likely change names since we decided not to use the command setenv to set these variables. We can’t be sure when we will be done with this though. For now I’d almost suggest you pretend you don’t have access to this stuff and do your changes later when this is all finalized.

To help us understand what you are doing with this component, can you give me some examples of what you are doing? Why are you referencing these nodes directly? Maybe you should make your own Null DAT and reference that? That’ll atleast help avoid issues when setenv_variables gets renamed.

not that much of an issue, forget about it. I’ll redesign my scripts to use variables for the paths to local/variables and when CVAR is available, it’s way easier anyway.

2 more thoughts:
How about, instead of variables DAT wire into a null DAT, having touch search all ops inside local which names match variables* (if not a speed issue). If it finds a non table DAT, you can just reference a variable and cvar varname will not work. This would allow to make the local/* stuff more easily scriptable (no opwire … needed).

Second, with the new options in the merge DAT, it’s now possible to easily override local variables, which is great. But in order to make local more scriptable it would be great if a COMP would have an overideLocal parameter (much like the override CHOP), where you specify a DAT which is internally used to replace cells in the variables DAT (so no need for having to create a merge DAT inside manually). If not, maybe the now used null DAT for variables reference could be switched to a merge DAT by default?