creating local variables, eval dat, store, fetch, examine

 To create a variable that exists at a level & for it's children, we use a text DAT.

Inside the DAT, type:

me.parent().setVar('variablename', 34)

now when you right click the text DAT and select run-script, it creates a little table that contains the variable + value

to access this, eg in the radius of a circle, type:

me.var('variablename')

the circle's radius parameter will now be 34.

This variable can be accessed by any nested children by typing the me.var('variablename') code

If you make a variable inside one of the children (lets say it's a Base), the parent will NOT be able to access it.

If you want a variable to have a changing value, eg. driven by a slider or LFO, you need to use an evaluate dat and a table. Go into the base that contains your variables.

inbetween the table & null, add your evaluate dat & connect a blank table as the 2nd input.

Give the blank table the correct dimensions & then make sure to recreate the "name" cell using the me.inputCell bit of "code".

In the value section we can use an op('../LFO1/.........'[0]) type of code to get the value we actually want the variable to have. Think of it as an override.

I can see this being useful, but also potentially confusing!! At least with the long op('../fsldjflsdjf') lines we can quickly trace back things. Perhaps leaving lots of sticky notes/ labels is the key. 

ALTERNATE VARIABLE METHOD

The other way is to use the store function.

In a Text DAT again, type "me.parent().store('name', 2.33)"

run the script, nothing happens.

To see the variable you just stored, make an Examine DAT and type in the name of the container you're in. eg. "../project1". You should see "name", the type <float> and the value 2.33 now.

In order to get this value to use in a parameter field, you use the FETCH function.

me.fetch('name')

And that's it! Not quite sure what the benefit of each is yet....