The Layer Tree

Although it is hidden at first, the underlying structure that powers the controllers menus and components is the so called "LayerTree". Think of it like photoshop for controller configuration: Different layers can be visible or invisible, and depending on that different Behaviors are visible on your controller. We will later see that these visibilities can be controlled by all kinds of Conditions, but for now: lets take a closer look at how the tree works.

The inverted tree

When looking at the tree you will notice that it does not unfold as in other applications (like a file browser). This is because we are looking at the tree from above like we are looking at the controller, layers and behaviors on top will be visible first, layers and behaviors further down might be covered.

The tree's Root Layer is the very base on the bottom. Layers can be opened and collapsed to show their sub layers (branches).

Multiple Files make up the tree

The Tree can be the combination of one or more layer files. The root layer is always the one defined by the current reactor project, but it can include other files that then get appended on the layer that includes them. To add a layerfile you can use the Included Layer File section in the layer's inspector window. When looking at the tree you can identify the places where other files have been included.

Having the tree split into separate files allows to reuse parts of the configuration in other places. This is sometimes referred to as Snippets. In our default configuration this is an essential concept, allowing to quickly switch out subconfigs like for example TallyForwarding or RoutingTriggers.

Layer Visibility and Behaviors

In the tree every layer can have an Active-If condition. Depending on this condition the layer is active or hidden. When looking at the tree in the configurator you can see if a layer is currently visible by looking at the blue border on the left side. If it is visible the layer is active, else it is hidden.

When a layer is hidden in the tree all it's elements are not used anymore. Behaviors defined on the layer, variables, sub layers, virtual triggers, layer scripts and other elements will also be hidden from the controller.

In the simplified example you can see the root layer. It defines a Behavior called Behavior1. As the layer 2 above redefines the behavior, the one that will be shown on the controller is the one defined on layer 2, as it is higher up in the tree. The Behavior Behavior2 is not covered and therefore the definition on the root layer is the active one.

Tree Elements

Layers in the tree include the definition of every other configuration element. These include:

• Behaviors
• Variables
• Virtual Triggers
• Flags
• PresetKinds
• Template Behaviors (aka MasterBehaviors)
• Constant Set Tables
• KeyMaps

In the tree view you can see most of these elements to make it easier to find them, and the layer that they are defined on. You can use the tree search function in the top of the tree to find them quicker. Additionally you can select which elements of the tree are shown.

Inheritance

When a tree element is defined on a layer it also gets inherited by all of its sub layers. Lets take a simple example of a variable

The variable myvariable is defined on layer 2. This means that behaviors defined on the layer can read and modify this variable. The same goes for all behaviors of sub layers of layer 2, in this case layer2.1

By following this basic concept we can understand which tree elements are available to which behaviors and layers. ¹

Types of tree elements

Lets take a look at the different tree elements and their functions

Behaviors

Behaviors are shown in the tree with their names. The color indicates if the behavior is selected and if it is visible (or covered)

When a behavior is shown in

• blue it is the currently visible.
• green it is the currently visible and selected.
• grey it is the currently hidden (covered by a different behavior above).
• orange it is the currently visible and selected.

Variables

Variables are shown in the tree with their key. Variables can have a key and a name, the name is a friendly name that will be shown, while the key is the actual reference to this variable that will be used in all Parameter References pointing to it. Changing the name will just make this variable show up different in several places, while changing it's key will actually break it's links to other points in the configuration.

Next to the variable you can also see it's current value. A variable can have more than 1 value at once, if that is the case the current values will be shown next to each other separated by commas

KeyMaps

A KeyMap can map the behavior names to different ones. Most of the time the keymaps are managed automatically by the configurator.

Any component of panel has a fixed address at the beginning. These have the following format

_p<panelID>.<componentID>

For example: _p1.15 (Panel 1, Component 15) or _p3.23 (Panel 3, Component 23)

To make our configurations compatible with multiple panels and to make them more understandable we use the keymap to map these addresses to a name.

A KeyMap can contain different kinds of mappings:

• Component address to behavior name: This is done to make the components have proper names in hte configurator
• Behavior name to behavior name: Remap a behavior alias to a different one in the layers below. Often used when a config is remapped to a different set of buttons
• Panel Wildcard (eg: _p1.*) to Panel Wildcard: Remap a panel ID used in the layers below to a different one. This is mostly used by the home screen to map your panels to their selected configurations.

Behavior to Behavior mapping and Panel Wildcard mapping are often used in combinations with the inclusion of different layer files. This use case id often used in combination with including layer files as described before (See Multiple Files make up the tree) to remap the ids used in the included config.

The KeyMap is shown in the tree on the layer where it is defined and it's mapping is valid for the layer itself and all its sub layers, like the inheritance of any other tree element.

Virtual Triggers

Virtual Triggers are defined on layers in the tree. When a layer becomes hidden the virtual trigger will also not be executed anymore. See more about virtual triggers in the chapter Virtual Triggers

PresetKinds

Preset Kinds define a Reactor Preset as a list of parameters that can be stored and recalled from your panel. You can read more in the chapter Flag Groups

Flag Group

Flag Groups are defined in the tree. Read more about them in the Chapter Flag Groups

Custom Template Behaviors

If you find yourself creating the same kind of behavior many times in your configuration you might want to create a Template Behavior yourself. In Reactor Setting Templates are also called MasterBehaviors.

You can create a Template Behavior on any layer and configure it to your needs. After this you can select the new template on all other Behaviors (in the scope of inheritance) See more in the chapter Custom Template Behaviors.

Constant Set Tables

Constant Set Tables are a Table structure that can be used for several things in Reactor:

For Example:

• Storing configuration that can be changed directly on the home screen
• Generating Pages of Behaviors based on Table Rows
• Creating several Virtual Triggers based on TableRows

As all other tree elements they follow inheritance. Learn more about the usage of them here: Generators and Constantsets.

Examples of Settings Tables in default configurations are:

• Camera Selector
• Tally Config
• GPIO Mappings
• (See more here: Default configurations)

Layer Paths

Technically every layer has a layer has a path. Paths are denoted for example like this: 0/1/4/1/

0/ always references the root layer. 0/0/ references the top most child layer of the root layer, and so on.

Knowledge of the layer paths is not required when you want to use reactor, but it can be useful to develop a better understanding of the system.