Reactor™ - The manual

SKAARHOJ Reactor™ is a powerful broadcast control application running on Blue Pill Servers and Blue Pill Inside-Products. Using Reactor you can

• do basic things like controlling your ATEM switchers, video routers and PTZ cameras etc.
• more advanced things like create powerful macros, that automatically start several Hyperdecks or position multiple PTZ cameras
• highly custom things like protocol translation

We aim to make common tasks and use cases intuitive and quick, but we also believe it's reasonable to expect users to invest time in learning to master our technology to fully utilize its advanced features. It's that balance that allows us to provide the entire spectrum in one package.

This manual aims to document most of the features available in Reactor. It will focus on helping you understand the basic primitives and concepts that make up the world of Reactor, help you master them, and serve you as a reference to a variety of topics.

Other useful information

Other articles and device-core specific Information can be found on the SKAARHOJ Wiki Pages:

-> wiki.skaarhoj.com

The main changelog of Reactor and other SKAARHOJ software can be found on devices.skaarhoj.com

-> Reactor Changelog

-> System Manager Changelog

Be sure to also check out out YouTube channel, with videos on many topics regarding our products

For example our Blue Pill - Basic Training Series

Other Infos can be found on our Website

Manual Version: online

Basics

In this chapter, we will provide a brief overview of the main areas of Reactor and the Blue Pill device's web UI.

We will cover:

• The Home Screen
• Projects
• The Configurator

The Home Screen

When you first open your Blue Pill product, you will see the so-called 'Home Screen.'

1. Right below the navigation on the top you can see the current project name, and also edit it's details by clicking on the pen.

2. On the left side you can add and configure panels

3. On the right side you can add and configure devices

4. You can access and edit all Reactor projects by clicking Manage Projects

5. In the bottom (footer) you can (from left to right):

• open the view settings. These are saved in your browser.

• change reactors global text size
• check the status of remote support mode (active when support text is yellow)
• find a link to the tools page (toolbox icon)

Devices

This is where you can add all connections to other devices on the network that you want to control with Reactor. Simply click "Add Device" at the bottom to open the device browser. You will see a list of all devices Reactor discovers on the network, using mDNS or other mechanisms. If your device does not support these, you can also click "Add manually" at the top and select your device from the list.

Panels

On this tab, you can add your panels. When working with a Blue Pill device, your panel should automatically appear when creating a new project.

Clicking on the panels name allows you to adjust its IP Address, name, brightness and sleep settings

After a panel is added, it will automatically select one of the available standard configurations. In many cases, these configurations are the generic SKAARHOJ default settings, allowing you to easily add devices from different manufacturers to your panel.

Below the selected configuration, you can see its configuration options. If the configuration includes a Camera Selector, you will also see which devices are already mapped to the controller, or you can add new ones. To configure the settings of your panel in more detail, click the blue name of the setting (e.g., Camera Selector, Switcher Inputs, Quick Class, etc.) to open them in a table.

Selecting Configurations for your Panels

Once you have added panels and devices, you need to select the preferred configuration for your panels. This is done using the dropdown menus. From here, you can choose one of the built-in default configurations or create a fully custom configuration by clicking "Create Custom Config" in the dropdown.

Using the small info icon, you can check additional details of your configuration, edit it in the JSON Editor, or delete/reset it to the system.

When creating custom configurations or modifying system configurations, you will see a small 'customized' indicator next to the configuration. Modifications are local to the current project.

Panel Groups

Panels can be grouped to set shared brightness and sleep time, and to provide additional organization.

This feature is disabled by default. Open the View Options (cog wheel in the footer) and activate it.

Groups can be renamed and their settings adjusted. Panels can be moved between groups, and sleep settings and brightness can be managed for multiple panels at once.

Projects

Using Projects, you can save and switch out the entire setup you have configured in Reactor, including panels, devices, and all configurations.

To do so, open the Project Window from Reactor's Home Screen by clicking on Manage Projects.

Manage Projects

Here, you can see all projects saved on the controller.

1. Use the buttons at the bottom to create new projects or import them from your computer. Reactor Projects are stored as .rpj (Reactor Project Format) and can easily be imported on other controllers.
2. You can use the search function to find your projects, or click the triangle icons next to the name or created columns to sort your projects.
3. Click Activate to switch the currently active project in Reactor.
4. Duplicating your project allows you to experiment with new configurations and revert to the previous state easily.
5. Click Export to export your project. Use right-click to get advanced export options.
6. Use the red trash can icon to delete your project.
7. Using the advanced toggle, you can show the components of your project. See below.
8. Click Manage Used Configs to view all sub-configurations that the current project includes (See Manage Included Configurations).

Advanced Project View

Under the hood, a project in Reactor consists of three parts:

• A panel collection, containing info about panels
• A device collection, containing all your cores and devices
• A root layer configuration, containing the actual layers of the configuration

These files can also be shared between projects. This is useful when you have the same set of devices or panels in a studio but want to run different configurations on different days. While you can duplicate the full project, it might sometimes be more beneficial to create these shared setups. In the advanced view of the project window, you can view and change the underlying configurations for the individual parts of your projects.

Manage Included Configurations

While your project might have one root layer configuration, Reactor uses several files to build the layer tree required for your project (See The layer tree).

In this section, you can get a quick overview of all configurations currently used in your project's layer configuration. This might include system default configurations, customized system defaults, or custom configs that you have created yourself. You can quickly view information about them and even delete them from this view.

Also note that you can upload configuration layers via this window, that have been downloaded from the Configuration'dropdowns Info Icon See Info Icon on Homescreen

Example:

This configuration includes a PTZ Pro that uses:

• its default (Standard Class) configuration
• Additionally, a Canon Camera has been added
• The Frame Shot Pro has two custom configurations created for it, one of which is used, while the other is not.

Here you can see how the scenario looks on the Used Configurations page:

Several Canon-specific system default configurations are included automatically. The unused Frame Shot config (created by the user) shows up below.

The Configurator

The Configurator (also sometimes called "Configuration Tab") is the main place where you can make customizations to your controller layout.

There are 4 main areas:

1. Controller Canvas:

   Here you can see and interact with your controllers. Check the legend (blue question mark in the top right corner) for tips on navigating the canvas with your controllers. You can zoom in and out by scrolling and move by dragging the mouse with a right click.

   Press ctrl+e (or cmd+e on macOS) to toggle between "configuration mode" and "simulation mode".

2. Inspector:

   Here you can see and adjust individual elements of the controller or the layer tree. The Inspector shows all properties of the currently selected object, such as a Component Behavior, Layer, Variable, or others.

   Sometimes, you may be looking at a Behavior that cannot be seen on the controller due to a different layer covering it. In this case, the Inspector will give you a hint and allow you to switch to the Active Behavior currently on top of the component.

3. Panel Selection:

   Use the blue buttons on the top to switch between different panels and focus on them. A green line will shou you the panel you are currently selecting. By clicking the button you will also select the panels root configuration layer (corresponding to the configuration file you selected on the dropdown on homescreen)

4. Section Selector:

   A Section in Reactor is a part of the controller that can have a menu with a few Pages. The section selector, located above the controller canvas lets you choose which section of the panel you are currently editing. SKAARHOJ default configurations often allow you to simply edit pages of existing menus. You can select these pages by clicking on their names, or add, remove, and rename them as needed. The Auto mode is the best way to always edit what you are seeing on the controller right now. If you just want to place new behaviors above any functionality of one of the SKAARHOJ Default configurations you can use the User Section to do so.

5. Undo / Redo:

   You can use undo / redo to revert changes you might have made on accident to the configuration.

6. Tree:

   The tree is initially hidden. You can show it by clicking the small green icon in the top left corner of the controller view. In the tree view, you can see all configuration layers. Every project has one root layer, on which your configurations are added as sub-layers. These can also have their own sub-layers and include other layer files. Read more about this here: The tree.

   Using the layer tree is recommended only if you're committed to learning more about the underlying technology in Reactor. The benefit is that, once understood, everything can be tweaked and modified without limits.

Reactor Configuration

In this chapter, we will dive into the details of controller configuration. We will explore the different components of a controller, the Layer Tree and its elements, and how they all work together.

We will cover the following topics:

• Components and Behaviors
• The Tree and its Layers
• Variables and Conditions
• The Parameter Reference (IOReference)
• Feedbacks and Actions
• Virtual Triggers
• Advanced Topics Note: This chapter will be added later 👷‍♀️

Hardware Components and Behaviors

What is a Hardware Component (HWC)?

Hardware Components are all the elements found on a SKAARHOJ controller or any Raw Panel compatible device (e.g., xpanel-* applications).

Some physical components, such as a joystick, can be represented as multiple Hardware Components in Reactor (e.g., Up/Down, Left/Right, and Rotate).

There are four basic types of hardware components:

• Buttons (Binary Inputs)
• Faders/Potentiometers (Analog Inputs)
• Encoders (Pulsed Inputs)
• Joysticks (Speed/Intensity Inputs)

Additionally, these components may have various types of displays linked to them.

Buttons can have different types of color LEDs to indicate status.

Larger displays can consist of different Tiles, allowing you to configure individual parts separately and easily.

What is a Behavior?

To configure what a specific component does and shows, we need to assign a Behavior to it. Click any hardware component in the configurator view to access the Behavior defined for it. If no Behavior has been created for this component yet, the inspector will show a palette of pre-configured Behaviors based on the devices you've added in the Home Screen.

To select a Behavior, simply choose the component you want to modify. If no behavior has been defined for the component yet, you will see the behavior palette in the inspector. You can select any preconfigured parameter from the list of your devices.

If you have selected a component that already has a configured behavior, you can click Change Behavior in the top right corner. This will reopen the behavior palette, allowing you to switch to a different one.

Manually Changing a Parameter in a Behavior

To manually edit a parameter inside a behavior (without using the preconfigured behaviors from the palette), click the Show More button. A yellow pen icon will appear next to the name of the parameter field. Click it and use the parameter reference helper window to configure the parameter you want.

 

Once you click submit, you will be presented with this window:

If you click the green Confirm button, you will use the Automatic Behavior Configuration.

This means Reactor will automatically select a Template Behavior and add configuration constants to your behavior. This makes it very quick to add almost any parameter to a component.

In some cases, you may want to keep the settings you have manually configured in the behavior. In these cases, simply click Keep current, and Reactor will only change the parameter reference.

Changing Template Behavior

Reactor does its best to choose the correct Template Behavior based on the type of component and the parameter you select. However, you may still want to change it. To do so, click Show More to display the Template Behavior dropdown.

The Template Behavior dropdown shows the most commonly used templates at the top. If you have created Template Behaviors yourself, they will also appear. If you cannot find what you're looking for, click Show All to display more included Template Behaviors from Reactor.

Available Template Behaviors

Here is a list of the most important Template Behaviors included in Reactor.

Custom Template Behaviors

You can also create your own Template Behaviors. See the chapter Template Behaviors in Advanced Configuration.

The Layer Tree

Although it is hidden at first, the underlying structure that powers the controller’s menus and components is called the "Layer Tree". For most people, this is initially an advanced concept, but it's extremely powerful and well worth understanding. 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 explore how these visibilities can be controlled by various Conditions, but for now, let's take a closer look at how the tree works.

The Inverted Tree

When viewing the tree, you will notice that it doesn’t unfold like hierarchies in other applications, such as file browsers. This is because we are looking at the tree from above, just like viewing the controller. Layers and behaviors on top will be visible first, while those further down may be covered.

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

Multiple Files Make Up the Tree

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

Having the tree split into separate files allows for the reuse of configuration parts in other places. This is sometimes referred to as Snippets. In our default configuration, this concept is essential, allowing for quick switching of sub-configurations like Tally Forwarding or Routing Triggers. For building most custom configurations, we recommend not splitting it into multiple files, as this tends to increase complexity.

Layer Visibility and Behaviors

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

When a layer is hidden, all its elements are also hidden. Behaviors defined on the layer, variables, sub layers, virtual triggers, layer scripts, and other elements are hidden or disabled from the controller.

In the simplified example below, the root layer defines a Behavior called Behavior1. Since layer 2 above it redefines the behavior, the one shown on the controller is the one defined on layer 2, as it is higher up in the tree. Behavior2 on the other hand is not redefined, so 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
• Preset Kinds
• Template Behaviors (aka Master Behaviors)
• Settings Tables (aka Constant Sets)
• Key Maps

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

Inheritance

When a tree element is defined on a layer, it is also inherited by all of its sublayers. Let’s 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 applies to all behaviors of sublayers of layer 2, such as layer 2.1. However, the two behaviors on the Root Layer - Treetest cannot access the variable myvariable.

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

Types of Tree Elements

Let’s take a look at the different tree elements and their functions.

Behaviors

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

When a behavior is shown in:

• blue: It is currently visible.
• green: It is currently visible and selected.
• grey: It is currently hidden (covered by a different behavior above or on a non-visible layer).
• orange: It is currently hidden and selected.

Variables

Variables are shown in the tree with their key. A variable can have a key and a name — the name is a friendly name displayed in the interface, while the key is the actual reference to this variable used in all Parameter References. Changing the name only changes how the variable appears in different places, but changing its key breaks the links to other parts of the configuration.

Next to the variable, you can also see its current value. A variable can have more than one value at once (an array); if that is the case, the current values will be shown separated by commas.

Key Maps

A Key Map can map behavior names to the physical hardware components on panels. They can also remap behavior names to different ones. Most of the time, Key Maps are managed automatically by the configurator.

Each hardware component of a panel has a fixed address format:

_p<panelID>.<componentID>

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

To make configurations compatible with multiple panels and more understandable, Key Maps are used to assign names to these addresses.

A Key Map can contain different mappings:

• Component address to behavior name: This assigns behavior names to hardware components in the configurator.
• Behavior name to behavior name: Remap a behavior name to a different one in the layers below, often used when a configuration is remapped to a different set of buttons.
• Panel Wildcard (e.g., _p1.*): 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 combination with the inclusion of different layer files. This is useful when remapping IDs in an included configuration.

The Key Map is shown in the tree on the layer where it is defined, and its mapping is valid for that layer and all its sublayers, 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 not execute anymore. See more about Virtual Triggers in the chapter Virtual Triggers.

Preset Kinds

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 Shading Presets.

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 repeatedly, you might want to create a Template Behavior. In Reactor, Template Behaviors are also called Master Behaviors.

You can create a Template Behavior on any layer and configure it as needed. Afterward, you can select the new Template Behavoir for other Behaviors (within the scope of inheritance). See more in the chapter Custom Template Behaviors.

Settings Tables (aka Constant Sets)

Settings Tables - or Constant Sets - are a table structure used for various purposes in Reactor, such as:

• Storing configuration settings that can be changed directly on the Home Screen.
• Generating layers with Behaviors based on table rows.
• Creating multiple Virtual Triggers based on table rows.

As with all other tree elements, they follow inheritance. Learn more about their use here: Generators and Constant Sets.

Examples of Settings Tables in default configurations include:

• Camera Selector
• Tally Config
• GPIO Mappings
• (See more examples in Default Configurations)

We call them Settings Tables because they often store important settings available from the Home Screen. Their original name, Constant Sets, reflects the fact that their values are stored within the configuration and cannot be changed while the controller is running, unlike variables. Any modifications require updating the configuration through the UI.

Layer Paths

Technically, every layer has a path. Paths are denoted as, for example, 0/1/4/1/.

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

Knowledge of layer paths is not required to use Reactor, but it can help you better understand the system.

Variables and Conditions

To better understand how menus and other logic can be created in Reactor, we need to understand Reactor's Variables and Conditions.

Variables

A Variable is, like many other things, an element in the tree (See Tree Elements). Variables are a concept used in programming and mathematics to store information. In Reactor, they can be used to store values like:

• the current page of a menu
• the currently selected Device ID
• whether the engineering menu is open
• and much more...

Types of Variables

Reactor variables can have two main types:

• Option List: A list of options, where each option can also have a label. Option values can be numbers or strings.
• Range: A numeric range with a minimum, a maximum, and a default (or center) value.

When a variable is set, the system checks if the value matches the possible defined values. If not, it will not set the variable unless the option Accept any value is checked under "Show More".

Basic Usage of Variables

Variables can be created on layers. The quickest way to do so is to select the base layer of your current configuration and add a variable. Start by clicking anywhere on the blue or black area of your controller. You should now see the root layer of this panel.

When a variable is created, its value defaults to the first value unless otherwise specified. From that point on, you can use your variables in all Parameter or Condition fields in any layer or behavior. Keep in mind that variables are available only to the layer they are defined on and its child layers. This follows Tree Inheritance.

Example:

The components on the layer MyCustomOverlay (1) and INLINE10-Custom-2 (2) can use the variable ShowCustomButtons (3). Components on the layer QuickBar-Custom-1 (4) cannot use the variable, as they do not inherit its definition.

To create variables that can be accessed by all layers, they need to be created on the main root layer of the project (5). The variable MyGlobalVariable (6) is accessible to all layers and controllers.

Setting and Checking Variables Using the Configurator

In the configurator, you can always see the current values of variables in the tree.

In the Inspector, you can also set different options active using the blue flag icon next to them.

Finally, you can use the bottom of the form to force set a variable or even set more than one value.

One Variable, Multiple Values

Any variable in Reactor can be seen as an array of values. While this array will only contain one element in most cases, it can also be empty or contain multiple elements. To add or remove values from a variable, you can use the Set Mode in the EventHandler config:

Here are the relevant ones explained:

• Add To Array: Adds a new value to the current value array.
• Remove From Array: Removes a specified value from an array.
• Clear: Clears all values of a variable, resetting it to an empty array.
• Toggle Add Remove: Adds a value to the array or removes it if it's already there.

Example: In a setup with multiple cameras, you may want to have one button controlling gain on several cameras at once. You can set up buttons to add more than one ID to the DeviceIndex to make this possible. ParameterReferences that already reference Var:DeviceIndex will now control all Devices in the array.

Conditions

Conditions are a structure used in many places in Reactor. They are text strings that combine multiple Parameters into a condition that can ultimately evaluate to either "true" or "false".

Some example places where they are used are:

• Active-If Condition on Layers: Determines if a layer is visible (rendered) or not.
• Active-If Conditions on FeedBack Handlers: Determines if a certain Feedback (e.g., Text, Color, etc.) is active or not.
• Active-If Conditions on Event Handlers: Determines if a certain interaction (e.g., left edge press) is active or not.
• Conditions on Virtual Triggers: Determines if a Virtual Trigger simulates an active button press (See Virtual Triggers).
• And several other places...

The Condition Helper Window

When you see a condition in Reactor, you can simply click it once to open the Condition Helper Window.

The helper window can make it quick to create the condition you need. You can:

1. Select Parameter References by clicking the yellow pencil icons or just start typing values into the text field.
2. Change the comparison operator in the middle to check.
3. Add logical branches to your conditions.
4. Change how your conditions are combined (AND or OR).
5. Edit the raw string value of your condition.
6. Evaluate the current result of the condition in Reactor by clicking the button. If true, you will see a green check ✅, else a red mark ❌.

Basic Format

The basic format of a Condition looks like this:

<Value or Parameter Reference> <comparison operator> <Value or Parameter Reference>

Comparison Operators

The basic operators for comparing values are:

• == equal to
• != not equal to
• < smaller than (only for numeric values)
• <= smaller than or equal to (only for numeric values)
• > larger than (only for numeric values)
• >= larger than or equal to (only for numeric values)

Combining Different Conditions into One

You can also combine several different conditions using the logical combination operators:

• && AND
• || OR

Additionally, you can use parentheses ( ) to group parts together and specify the order in which the individual parts of a combined condition are evaluated.

Example:
Var:MyVariable == true && (DC:bmd-atem/1/programInputVideoSource/1 == 5 || DC:bmd-atem/1/programInputVideoSource/1 == 8)
This will evaluate to true if the variable MyVariable is set to true and the Program Parameter of the ATEM device 1 (on ME1) is either 5 or 8.

Example:
Var:MyVariable == true && DC:bmd-atem/1/programInputVideoSource/1 == [5,8]
This is the same, but shorter, using an array for the literal values 5 and 8, which implies an OR operator.

Checking Against Empty or Zero Values

When checking if a value is empty, there are different possibilities to consider:

• A value can be completely undefined: In this case, we can check against an empty array [] or [''].
• A value can be an empty string: In this case, we can check against ''.

Inside of the Condition Helper Window, you will get these values recommended in a dropdown.

Example Usages of Variables and Conditions

The simplest use case for variables and conditions is to switch the visibility of a layer on and off. To do so, simply create a Variable — let's use "ShowCustomButtons" as the name for this example.

In the variable settings, set it to "Options" (1), click "Add option" (2), and add true and false options (3). We can also add labels (4) to these options — let's type in "Show" and "Hide" for this example.

The next step is to add our custom layer.

(If the tree is not open yet, click the green arrow in the top left corner (1)).

We can click the config layer (2) of our controller's config and click the Add Child Layer button (3).

Let's add two Behaviors to our buttons. To do this, we click the layer (1), select the two components by dragging (2), right-click them, and choose Create Behaviors (3). By default, Reactor will create dummy behaviors that show their button name and layer path.

We also need to map one of the encoders of our controller to the variable we just created. Simply click the component, choose System -> Change Variable from the sidebar, and select the Variable ShowCustomButtons.

Finally, we need to add an Active-If condition to our layer. To do this, click the layer and select Add Active-If Condition in the inspector.

On the left side, click the yellow pencil and select the variable ShowCustomButtons. On the right side, you can just type out true.

Click "Submit", and we are done.

To check the result, activate simulation mode (ctrl/cmd+e) and change the variable using the encoder. It should look like this:

The Parameter Reference (aka IO Reference)

One of the fundamental concepts in Reactor is the Parameter Reference, also sometimes referred to as IO Reference. This is a text string used to address any parameter within Reactor. Parameter References are similar to URLs, providing a consistent method for accessing and manipulating data. The main groups of addressable parameters are:

• Device Core Values
• Variables and Flags
• System Values
• Presets
• Panel Settings
• The current Behavior and its settings
• A value from a specific Settings Table

Additionally, the parameter reference can also include simple (literal) values, like a number or a text string.

Configuring Parameter References using the helper window

In Reactor, wherever you encounter a Parameter Reference, you can open a helper window to select what you need easily. You can also configure the Parameter Reference manually if you wish.

The helper window consists of several parts:

1. The top displays the actual text string being built by the options you choose.
2. Select the type of Parameter Reference you want to create.
3. Configure the Parameter Reference; in this case, select the parameter of a device. The form will show more options as you make selections.
4. Click the Edit Raw button to directly edit the Parameter Reference text string.

Manual Configuration

To manually configure a Parameter Reference, you must first understand the format and the possible options that make up the reference.

Basic Format

The basic format looks like this:

Type:part1/part2/part3:modifier1:modifier2:modifier3

Some parts can include nested Parameter References using curly brackets { }, allowing a different Parameter Reference to select a certain device ID for example. This is valid in some combinations but not universally. Refer to the specific option in the reference for more information about templating.

It is also possible to create a Parameter Reference that points to multiple parameters using array syntax with [ ] for IDs.

Types and their Options

Different Types of Parameter References can have different options or modifiers.

The current Behavior and its settings (Behavior)

Behavior parameters reference values configured for the current Behavior or display related information. These are often used in Template Behaviors.

Format: Behavior:[subtype]:[additional type]:Modifiers...

Examples include accessing the main parameter’s value or name using Behavior:IOReference:Name (to display the name) or Behavior:IOReference:Current (to display the current value).

Subtypes

• IOReference (main parameter reference)

Using this subtype, the main parameter in the behavior can be referenced. Additionally, modifiers can be added. This allows you to refer to the main parameter's value or name without hardcoding it in other parts of a behavior (such as Feedbacks or Actions).

Examples:
Behavior:IOReference:Name (Displays the main parameter's name) or
Behavior:IOReference:Current (Displays the main parameter's current value).

• Const (BehaviorConstant)

Using Behavior:Const:[constant key], you can access constant fields of the behavior. This allows you to create SettingsTemplates for behaviors with customizable constant fields. It is used in many built-in Template Behaviors.

Advanced Subtypes

Several other subtypes exist to access information about the current behavior:

• Name - The friendly name of the behavior.

• Path - Returns the "path" of the behavior in the layer tree, e.g., "0/3/0/A3".

• ID - Returns the behavior's main mapping to a panel, for example, "_p4.32" (panel ID 4, Hardware Component (HWC) 32).

• Panels - An array of all panel IDs this behavior is mapped to (used mainly for accessing panel parameters, see below at Panel Settings).

• Script - Using the Script subtype, you can access information about the currently running scripts of this behavior. See Scripting Engine.

• LastEvent
  Access information about the last hardware event (trigger) received by the behavior.

IO Reference	Comment
Behavior:LastEvent:Type	Type of last event. Options: Binary, Pulsed, Analog, Speed
Behavior:LastEvent:TimeToNow:[Limit]	Returns the time in milliseconds that has passed since the last event. Although setting a limit is optional, it's recommended to set it at or above the comparison value for performance efficiency. If a limit is set, it designates the maximum returned value.
Behavior:LastEvent/Binary:Pressed	Returns whether the last binary trigger was pressed (ActDown) or not (ActUp). Options: true, false
Behavior:LastEvent/Binary:Edge	Returns which edge the last binary trigger sent. Options: NoEdge, Top, Left, Bottom, Right, Encoder
Behavior:LastEvent/Pulsed:Direction	Returns the direction of the last pulsed trigger received. Options: Up, Down
Behavior:LastEvent/Pulsed:Value	Returns the value of the last pulsed trigger
Behavior:LastEvent/Analog:Value	Returns the value of the last analog trigger (0 to 1000)
Behavior:LastEvent/Speed:Value	Returns the value of the last intensity trigger (-500 to 500)

• Events
  Access information about the last Action executed on the behavior.

  Behavior:Events/[Action Name]:TimeToNow:[Limit]

  Returns the time in milliseconds since the last accepted trigger for the specified action. Setting a maximum limit is recommended for performance reasons in Reactor.

  Behavior:Events/[Action Name]:SequenceStep
  The current sequence step being executed (see Binary Sequence).

Modifiers are used by certain Parameter References to access additional information or present the data in a different format. Modifiers are simply appended to the Parameter reference like this:

ParameterReference:Modifier1:Modifier2 ...

Most of the time, modifier combinations are dependent on their order.

Not all Parameter types support all modifiers. Reactor will limit the selection based on your Parameter selection in the helper window.

Here is a complete list for reference:

Feedbacks and Actions

So far, we have been using the included Template Behaviors to define how a component interacts with a parameter.

When we want to customize individual parts of a behavior or even create one from scratch (without selecting a Template Behavior), we need to understand Feedback Handlers and Actions (formerly known as Event Handlers).

Feedback Handlers

Feedback Handlers are the parts of the Behavior that define what a component shows. They can adjust things like LED color, display text and elements, and even the position of a motorized fader.

Every Behavior and Layer has a Default Feedback, which is shown automatically. Additionally, there are Conditional Feedbacks, which are only active when their Active-If condition returns true.

Let’s take a look at the available fields in a Feedback Handler:

There are several groups of fields:

General Feedback Fields

Description

Give your Feedback Handler a readable description. This will be shown in the header and can make your behavior easier to understand.

Intensity

Intensity defines the strength of the LED light. It can be Off, Dimmed, or On.

Color

Set the LED Color. You can select one from the color picker or even use a parameter to define the color of a component.
NOTE: You will not see a color show up if Intensity is OFF.

Blink Pattern

Make the component blink in a certain pattern. This is useful for cases where you want a button to attract additional attention, like warnings or other alerts.

Text Display

Solid Title Bar

Select whether the Title Bar should have a solid white background or be transparent. In SKAARHOJ default configs, a transparent title bar is often used to indicate that a button "Sets" the value written on it, while displays with a solid header bar usually show the current state of a value.

Textline 1 & Textline 2

Specify the main text for the component. You can add dynamic values with parameters into the text using the helper window or braces {}.

Simple Icons

Icons

Set a condition for when to show the lock icon.

State Icon NoAccess

Set a condition for when to show the no access (forbidden sign).

State Icon Fine

Set a condition for when to show the fine icon, generally used to indicate when coarse mode is active.

Advanced Feedback Fields

Show Value Indicator Bar

Here you can specify a Parameter to use for a small value indicator below the main display content. Make sure you use the correct modifiers for the parameter, EG: Behavior:IOReference:Current:Normalized

Actions

Actions are the parts of the Behavior that define what the component does when it is interacted with in various ways. Multiple Actions can be added to each behavior to enable different types of interactions or control different parameters.

Actions can also have an Active-If condition, but unlike Conditional Feedbacks, Actions are always active by default.

General Action Settings

Let's take a look at the available fields in an Action:

Handler Type

The Handler Type is a special field that determines the other available fields for configuration.

An Action can have one main type of trigger it interacts with. The trigger types are (as described earlier in Hardware Components): Binary, Pulsed, Analog, and Speed.

• A Binary Component can create ActDown and ActUp triggers.
• A Pulsed Component can create Pulsed Value triggers, like +1 and -1.
• An Analog Component can create Analog Value triggers from 0 to 1000.
• A Speed Component can create Speed Value triggers from -500 to +500, resetting to 0 when released.

After selecting the Handler Type, you can still add PreProcessors to the Action, which define how to respond when a different trigger type is received.

General Action Fields

Specific Settings: Binary

Specific Settings - Pulsed

Specific Settings - Analog

Specific Settings - Speed

Speed handlers currently don't have configuration options exposed in the UI.

Advanced Action Fields

Inheritance of Feedback and Event Handlers from Template Behaviors

When adding Feedback Handlers to a behavior that uses a Template Behavior, they will be combined with those from the template. Feedback Handlers defined in the template are marked as Inherited.

Feedback Handlers with the same index number in both the template and the behavior will be merged (overridden). The same applies to Actions with the same name.

In the example above, after modifying the Feedback Handler with index 10 (changing the color), the fields inherited from the Template Behavior's Feedback Handler with index 10 are still visible.

Virtual Triggers

While a component can generate triggers, sometimes you might want to trigger something based on an external event, such as a parameter change on one of your switchers. To facilitate this, Reactor can generate a trigger based on:

• Conditions
• Time
• Value Changes

Modes

Virtual triggers can operate in one of the following modes:

Creating and Configuring Virtual Triggers

Like many other elements, VirtualTriggers are part of the tree and are defined on a layer. To keep things simple, it is recommended to create VirtualTriggers on the base configuration layer of your configuration. Start by clicking anywhere on the blue or black area of your controller. You should now see the root layer of this panel.

To create a VirtualTrigger, follow these steps:

After creation, click on the name to edit it. You will see this in your inspector:

1. When adding a Virtual Trigger, first select its mode using the dropdown.
2. After creating a trigger, select either a Condition, Parameter Reference, or time schedule.
3. Click Create to create a Behavior.
4. Click on the Behavior to configure a behavior that will be used for the Virtual Trigger.

Configuring 'Schedule' Virtual Triggers

Schedule Virtual Triggers use a configuration format called Cron. Cron is a Linux application that schedules commands or scripts to run automatically at specified times and dates.

The syntax works as follows:

All six fields are required.

Allowed special characters explained:

• Asterisk ( * ) The asterisk indicates that the cron expression will match all possible values of the field. For example, using an asterisk in the 5th field (month) would indicate every month.

• Slash ( / ) Slashes describe increments of ranges. For example, 3-59/15 in the 1st field (minutes) would indicate the 3rd minute of the hour and every 15 minutes thereafter. The form */... is equivalent to first-last/..., meaning an increment over the largest possible range of the field. The form N/... is accepted as meaning N-MAX/..., starting at N and using the increment until the end of the specific range. It does not wrap around.

• Comma ( , )
  Commas separate items in a list. For example, "MON,WED,FRI" in the 5th field (day of the week) would mean Mondays, Wednesdays, and Fridays.

• Hyphen ( - )
  Hyphens define ranges. For example, 9-17 would indicate every hour between 9am and 5pm inclusive.

• Question mark ( ? )
  A question mark may be used instead of * to leave either the day-of-month or day-of-week field blank.

Alternatively, we also allow the following inputs:

Videos

We currently have 3 videos on our YouTube channel documenting Virtual Trigger Configuration:

Reactor Parameter Presets

Reactor Shading Presets allow you to define a list of parameters that can be stored and recalled from your panel. You can combine any device core value on any device and recall it for either the same or a different device.

To get started, create a Preset Kind on a layer in the tree. To keep things simple, we recommend creating Preset Kinds on the configuration layer related to your panel. Start by clicking anywhere on the blue or black area of your controller. You should now see the root layer of this panel.

Next, go ahead and add a new Preset Kind. Preset Kinds are hidden under the "Show More" toggle of the Layer Inspector

Afterward, you can start adding parameters to the Preset Kind. Click "Add Parameter" Select the Device Core, then select the parameter you want to control.

When you're satisfied with your preset, you need to map buttons for storing and recalling presets. To do this, create a new Behavior on a button and open the parameter (yellow arrow).

Select Presets, then your newly created Preset Kind. For the device ID, you can either choose a fixed device that this button will store and recall a preset on or select a Variable like DeviceIndex to use. Finally, choose a preset number that this button will store and

Select Store as the action. Preset ID you can choose a number freely, specify a DeviceID or leave empty to pick the Systems DeviceIndex Variable (if available in your configuration)

When using the Automatic Behavior Configuration Reactor will automatically select the "Long or Short Press" Template Behavior for you, makking it with a "Store" action on a Long Press (button will blink green) and a "Recall" on short press.

You can now use the button to store and recall a preset with your specified parameters 🎉

Advanced Topics

In this chapter, we will explore some of the more advanced topics in Reactor's configuration. Many of these concepts are used extensively in our default configurations, and learning about them will provide a deeper understanding of what is happening within our built-in configurations.

We will cover the following topics:

• Settings Tables and Generators
• Flags
• Custom Template Behaviors
• Scripting in Javascript
• History View
• The JSON Editor

Settings Tables and Generators

Settings Tables and Generators allow Reactor to provide complex dynamic configurations. This mechanism is primarily used in SKAARHOJ Default Configurations, but can allow you to build dynamic configurations yourself, that can be adapted very quickly from the home screen.

Common usecases for Settings Tables can be

• Storing configuration that can be changed directly on the Homescreen
• Generating layers with behaviors based on table rows
• Creating several Virtual Triggers based on table rows

In the following sections we will take a look into each of these usecases.

Setting Tables

Settings Tables, like all other tree elements, follow inheritance. (See Tree Chapter)

Examples of Settings Tables in default configurations include:

• Camera Selector
• Tally Forwarding
• Routing Triggers
• GPIO Mappings
• (See more here: Default Configurations)

Reactor's constants are values embedded in the configuration code, used for various purposes within the configuration. Unlike variables, constants can only be modified by altering the configuration.

Settings Tables in Reactor are essentially tables of related constants (this is why they have been known as Constant Sets in earlier versions of Reactor). Each row forms a set of constant values, and columns represent different constants within these sets.

They can be used for a variety of functions, such as setting switcher inputs or configuring a PTZ controller's camera selector. Simpler uses might include single-row Settings Tables for configuring specific aspects of a configuration, such as the number of cameras on a page.

Example 1: Storing configuration that can be changed directly on the Home Screen

In this example we will create a simple Settings Table, that allows us to change the first button's color from the home screen. This is just an example. Using this technique you could use any kind of setting, control layer visibilities, button behaviors, default colors or other aspects of your configuration directly from the Homescreen. This can be great to build simple configs that can be customized by less technical users.

To create a new Settings Table for a controller simply click on your controllers black or blue background (1), open Show More (2) in the inspector and add a new Settings table

Next click on the name of your new settings table to open it in the inspector. You will see a blank table without any columns (constants). To add some columns let's add Constant Definitions. You can do that easily by creating them in the top of the Settings Table inspector

By default new Constants will have the type String, but this can be quickly changed, by clicking the constant and selecting a different type from the dropdown. You can also open show more and check if the constant should have a label or not. You can use the back button in the right top corner of the inspector to get back.

Lets create 2 Constants: a SettingName and a Value. SettingName should be a String and Value a Color. Afterwards you can add the first row into the Table.

We can now open Show More and select Show on Homescreen in the bottom. This way we can now edit the contents from the home screen. Notice that you can not edit your Settings Table from the Configuration Page directly anymore.

Your Settings Table should look like this:

To make our newly created table actually do something we will create a empty Behavior on the first button of our controller Then we need to select Intensity: Dimmed and add a Color, open the color picker window by clicking on the 'Empty' Text.

Now select 'Param' in the color picker, and a Parameter Helper Window will open. Here we can now directly select 'Settings Table' and pick our row (0 in this case) and select the Value field.

Great! 🎉

The button now shines in the color that is selected in the table from Homescreen

Example 2: Creating Several Virtual Triggers from a Table

Another use case is to create several, similar Virtual Triggers, one for each row in a Settings Table. This can be useful if you want to listen for a change of a parameter for several cameras, or trigger complex routings on an ATEM mixer, depending on the state of its inputs.

For our example we want to create a table of Aux Channels. We will create a Virtual Trigger that can link an AUX Channel from one ATEM Mixer to another. Users can then add or remove rows to the Settings Table and therefore link or unlink Aux Channels between the two devices. This is just an example, there are many other things that can be done here

To get started let's create a Settings Table on our Controller. It will have 2 columns: AuxAtem1 and LinkedAuxAtem2. We can add 2 entries for linking AUX1 of our first Mixer to AUX2 of our second mixer and AUX2 of the first to AUX3 of the second. (This example assumes two ATEM Mixers with more than 4 AUX Outputs)

The Settings Table should look like this:

Then we click the controller again and add a new Virtual Trigger. The Type we will use should be Change. Click 'Show More' in the Virtual Trigger Inspector and scroll all the way down. Select the Settings Table from the dropdown in 'Generate multiple from Settings Table'

It is good to do this step first, as it will now ensure that the names of the table columns will show up in the Parameter Helper Window when we configure our Virtual Trigger.

Next select the parameter to monitor. We select the ATEM 1, Parameter: AUX Source, and for Aux Channel: Behavior:Const:AuxAtem1. This represents the first column from our table.

Now we select the parameter in the Behavior (the Then section of the Virtual Trigger). The parameter we want to set this time will be the ATEM 2, Parameter: AUX Source, and for Aux Channel: Behavior:Const:LinkedAuxAtem2.

Important Note: This time the Automatic Behavior Configuration will not help us, so we select "Keep current" when asked, and select "Set specific value" in the Template Behavior Dropdown ourselves.

Finally we need to select the Value that we want to set into the second mixer's AUX channel. This will basically be the same parameter reference as we used as the trigger: ATEM 1, Parameter: AUX Source, and for Aux Channel: Behavior:Const:AuxAtem1

Done! 🎉

Reactor will now create a separate VirtualTrigger for each row of the table and execute when a change happens.

We can now change the first ATEMs Aux channel 1 or channel 2 and should see the change on the second mixer AUX 2 and 3

Generators

Generators are the second piece of the puzzle if you want to use Settings Tables to dynamically create parts of your configuration (Behaviors and Layers). When a Generator is created on a layer it can create behaviors and even new sub-layers. It needs to be noted that only one generator can be created per layer.

Think of a Generator like something that can generate several pages of layers and behaviors based on a template

There are several different Types of Generators with different functions.

• Behavior Generator: The most common type, used to create 'pages' layers for a larger amount of behaviors.
• Channel Pages: Mostly used in AudioConfigs, where an entire Layer gets repeated. (eg: a channel group on the Waveboard, consisting of Fader+Display+GainEncoder, hence the name of this type)
• Import Config Selector: Used to include a specified Configuration Snippet on a sub-layer, most commonly used in the Camera Selector.

For now we only have a example and sufficient UI support for the first type Behaviors. For the other types you will need the JSON Editor to specify the exact layer and behavior templates.

Example: Creating Pages of behaviors for a row of buttons

Often we need a row of buttons to perform a very similar task, for example a Preset Recall or a Video Input Selection. This means that all buttons (or other components) in this row will often use a very similar Behavior, with minor changes from button to button, like a different preset number, label or color. Sometimes we might also want to create several pages of these buttons (for example preset 1-20 mapped on a row of 5 buttons and one paging button)

We can achieve this by copying the same behavior on all of the buttons and working with the Batch editor, but that gets tedious quickly, and does not provide a lot of flexibility after the fact.

To solve this task in a more elegant way we can create a Settings Table first, that will hold all the preset numbers and labels. Then we will use a Generator to turn the rows of the table into several pages of behaviors for the buttons. Finally we will map the page variable to a button, so we can cycle through them.

Lets get started:

First click anywhere on the controller you want to use to select its main layer, then open "Show More" and create a new Settings Table. we will call it "Presets"

Now click the new Table and add some Constants (Columns). We will add a Preset Number, a Label and a Color. After creating click on the individual Constant Definitions and change their types accordingly to "Integer", "String" and "Color". Optionally also enable 'Show on Homescreen after you are done with everything' After doing so your Settings Table should look like this:

Now we switch to the Homescreen to edit the contents of our table

We can add several rows to our set. After adding a first row we can use the (then visible) "New (multi)" Button to create our 20 Presets

Back to the Configuration Tab, click the controller again to select it's main layer, now let's create a Generator to turn the rows of the table into Behaviors.

Select the Settings Table created in the beginning as the Data Source (1) for the Generator, then specify the page size (3). You can also override the default name of the page variable(2). (This variable will be created automatically by the generator if it does not exist already). In this example we name it PresetPage.

The component prefix(4) will determine how the new behaviors map to your controller. You can only choose HWCs with continuously named key labels. If this is not the case on your particular controller, a (KeyMap is needed to correct for that). In our example our prefix will be X.

You can use the page offset(3) in combination with the page size(3) to adjust the location of your generated behaviors, we leave them on 4 for size and empty for offset.

Configuring the Template Behavior

Now we need to configure what content is put on our buttons. To do that we select the template behavior, for our example we will select a PTZ Preset Recall function from the Canon Core. For the Preset Number we can select Behavior:Const:PresetNumber.

For the label and Color we need to add these to the feedback. Use the same method of selecting the Behavior:Const Value to access the field from the original Settings Table in the Behavior.

Configuring the Page Button

As a final step we need to map the generated page Variable to a button, to be able to change the current page. Todo that click the next button and select the Page Variable as the parameter on a fresh behavior.

Done! 🎉

Reactor will now create as many sub-layers as needed, with one behavior for each row of the table. The table content can then be changed and the pages will be automatically updated. In the tree you can now see all elements that are managed by the generator in purple:

Summary

Settings Tables and Generators can be a bit intimidating at first, but when used properly they can be a super powerful tool to take your configurations to the next level. Feel free to explore the use of generators in our default configurations, as there are many tricks to find there.

Custom Template Behaviors

To simplify repetitive configuration tasks, you can create your own Template Behaviors. These are sometimes referred to as Master Behaviors in Reactor (similar to a MasterSlide in PowerPoint or Keynote).

For example, suppose you want to create a custom behavior for an Encoder that performs a preset recall with a left turn and a preset store with a right turn. Additionally, you want the encoder to have a green ring light.

Once configured, you can reuse this encoder across multiple places in your configuration, controlling different preset IDs. This is a perfect use case for creating a Template Behavior.

Creating and Configuring Template Behaviors

Template Behaviors are a Tree Element and can be defined on a layer, following the usual scheme for Inheritance, as explained in the Tree Chapter.

To keep things simple, we recommend creating Template Behaviors on the global Root Layer of your configuration or the configuration layer related to your panel. In this example, we will use the second option. Start by clicking anywhere on the blue or black area of your controller. You should now see the root layer of this panel.

Next, add a Template Behavior. You can also use the "Copy From" function to copy the current behavior of a component into a new Template Behavior.

Afterward, you can configure your Template Behavior just like any other Behavior. ¹

Using Constant Definitions to Add Fields to the Template Behavior

When creating Template Behaviors, it’s often useful to make certain parts of the nested configuration available at the top of the Behavior form. This is best done using Constants.

You can define Constants by adding Constant Definitions to your Template Behavior. Type a name for the new Constant (1) and press Create (2).

Once added, the new fields will be available at the top of the form (3).

Click on the definition to edit the properties of the new field. You can choose its type, add an extra label, and limit how many values it can hold.

Using a Custom Template Behavior

Once you have created your Template Behavior, you can use it in the Template Behavior field of any Behavior that inherits it.

Flag Groups

In Reactor, a flag group is a structure used to store tally and routing information. It is a matrix of values, each with a color and a label.

The available colors are:

• Red
• Green
• Blue
• Yellow

Flag Groups are used in all default configurations for Tally Forwarding and Routing Triggers.

Creating and Configuring Flag Groups

Flag Groups are a Tree Element and can be defined on a layer, following the usual scheme for Inheritance, as explained in the Tree Chapter.

To keep things simple, we recommend creating Template Behaviors on the global Root Layer of your configuration or on the configuration layer related to your panel. In this example, we will use the second option. Start by clicking anywhere on the blue or black area of your controller. You should now see the root layer of this panel. Next, go ahead and add a Flag Group.

Once you have created a flag group, you can use it right away.

Flag Groups are Global

One of the most important settings of a flag group is its Group Index. This number is similar to a TSL Screen ID. Flag Groups with the same Group Index will share their state, no matter where they are defined in Reactor. You can use this to make two controllers share the same tally information or to separate tally for controllers by using a different number for the index.

Controlling Flags from a Behavior

Flags can easily be set from a Behavior or used in a Condition. To do this, simply select Flag in the Parameter Helper Window.

Once you have selected a Flag, you can use Hold Down, Change By Step, or Set Specific Value Template Behaviors to control it. For GPO contacts, we usually use the Output Template Behavior.

Flags behave like any other Boolean Parameter. They have a value called 'true' and one called 'false'.

See more here: Parameter Reference.

Monitoring and Debugging Flag Groups

If you open "Show More," you can see the first 150 flags as switches. This allows you to monitor their state and also control them manually while working on your configuration.

(Note: The number of flags is technically unlimited, but only the first 150 are shown in the inspector for performance reasons.)

SKAARHOJ Default Configurations

Out of the box, we provide a quick setup to get you started controlling your devices. We’ve created a curated set of configurations to make it easy to add and combine devices from different manufacturers with our panels.

Panel Classes

To create systematic configurations, we’ve developed Configuration Classes, categorizing each SKAARHOJ panel by its intended purpose.

The following Configuration Classes exist:

• Camera Light Class
• Camera Standard Class
• Camera Pro Class
• Switcher Class
• Audio Class
• Quick Class
• Routing Panels
• MegaPanel Configurations

Camera Light, Pro, and Standard Class

Pro and Standard Class compatible panels are used for shading and PTZ control. A Pro Class panel has a menu based on 8 standard encoders, while a Standard Class panel has a menu based on 4 standard encoders.

These configurations are usually called "Generic Camera Control."

Light Class Panels

• PTZ Wiz
• Air Fly Pro (V2 and V3) Wiz Section

Standard Class Panels

• PTZ Fly
• PTZ Pro
• Color Fly
• Right Side of Rack Fusion Live

Pro Class Panels

• PTZ Extreme (V1, V2)
• RCP Pro
• RCPv2
• PTZ View (aka MKA 2)
• INLINE 22 + XC 7

Configuration Options

In these configurations, each panel has a Camera Selector, a Tally Forwarding Config, and a Routing Trigger Config.

The Camera Selector allows you to add different cameras. Each panel has a dedicated button row for camera selection. Depending on the device core used to connect the camera, a different menu will be loaded when the camera is selected. You can also configure its name, tally index, and routing index in the Constant Set Table.

Switcher Class Configurations

Switcher Class configurations are designed for live switching controllers and device cores. They provide the most common functions needed to control a switcher system while offering advanced features for deeper control, such as the Quick Class or PTZ sections.

Switcher Class Panels

• Air Fly
• Air Fly Pro (V1, V2, V3)
• Master Key One (V1, V2)

Audio Class Configurations

Audio Class configurations are default setups for controllers with at least four faders as the main components.

To use them in Reactor, select a "Generic Audio" configuration for your panel and fill the channel configuration with devices.

Audio Class Panels

• Wave Board (V1, V2)
• Wave Board Mini
• Color Fly (V2, V3)
• Wave Board (V1) ¹

Quick Class Configurations

Quick Class configurations work with a Quick Bar and selected controllers that have a section of six Four-Way buttons. Select a Quick Class configuration in Reactor and fill the selector with the devices you want to control.

For more info, visit:

• Quick Class Configurations
• Quick Class

Routing Configurations

Routing Configurations map router devices to utility controllers like the Rack Fly series or the Quick Bar.

MegaPanel Configurations

SKAARHOJ MegaPanel configurations typically consist of one large configuration for several controllers, often based around a T-Block (Left or Right).

One M/E row usually consists of two Master Key 48s and one T-Block. Additional modules, such as the Wave Board Mini or PTZ View, can also fit the MegaPanel frame.

Understanding Sections in Default Configurations

The default configurations provide a few easily configurable sections.

User Section (1)

The User Section exists in all SKAARHOJ default configurations. It covers nearly all components of a panel. When you create a behavior in the User Section, the new behavior overlays those defined below, allowing you to easily modify button functions even if they are deeply embedded in the default configuration.

Camera Adjustments (2)

The Camera Adjustments section is present in all camera-related configurations (Light/Standard/Pro Classes). The menu corresponding to the selected camera’s device core is loaded and can be customized here.

Engineering Menu

The engineering menu contains panel settings like, Brightness control and dim/sleep time. You can also find other settings like, expert mode and global Invert pan/tilt or the Panels IP Address.

It can be accessed in different ways based on the panel, and chosen configuration.

How do I know which method my configuration is using? Here we have listed the different default Configurations that have the engineering menu.

Remember this is a list of configurations. So the specific panels named here, only have access to the engineering menu, when the loaded configuration contains such menu. This also means that you will find panels not named here, that can also access an engineering menu. To find the exact method used in your panel config, you can navigate the list here, and try methods that is in correspondence with your panel type.

PTZ Pro

How To Activate

Press and hold U4 A for a few seconds

Models with this method

PTZ Pro only

PTZ Extreme

How To Activate

Press and hold A for a few seconds

Models with this method

PTZ Extreme only

RCP

How To Activate

Step 1) Press and hold the 'Shift' button A

Step 2) Now press the 'Panel lock' button B to enter the engineering menu

Models with this method

All RCP models, with the config "RCP - Generic PTZ Control"

All other Configs with Camera Selector

How To Activate

Press and hold the top edge of the 'Page' button A for a few seconds

Models with this method

Listed here is 4 panels that have support for a configuration, that have an engineering menu accessible the same way. Remember this is just examples, and that this method is not exclusive to these 4 panels.

Mega Panel

How To Activate

Step 1) Press and hold the 'Shift' button A

Step 2) Now press the 'Panel lock' button B to enter the engineering menu

Models with this method

MKT1A, MKT1B, T-Block-Left, T-Block-Right

Kairos

How To Activate

Step 1) Press and hold the button marked A

Step 2) Now press the button marked B to enter the engineering menu

Models with this method

Master Key One V2 with Kairos Config

All other Switching Configs

How To Activate

Step 1) Press 'Shift' A to make the FTB button light green

Step 2) Press 'FTB' B to enter the engineering menu

Models with this method

Listed here is 3 panels that have support for a configuration, that have an engineering menu accessible the same way. Remember this is just examples, this method is not exclusive to these 3 panels.

Tips and Tricks

Using Context Menus

In many areas of Reactor, you will find context menus by right-clicking to interact with elements. These can help you work faster. Here are a few examples:

• Remove a panel faster using right-click.
• Copy Variables in the Tree quickly.
• Create behaviors on the controller.
• Clear the contents of behaviors easily.

Use Shortcuts

Shortcuts are a great way to speed up your workflow in Reactor. Here is a list of the most useful ones:

• cmd+e: Toggle simulation mode in the configurator.
• cmd+u: Upload a new package manually (works everywhere).
• Hold shift on Add Device or Add Panel: Add a device or panel without closing the window, allowing you to add multiple devices faster.
• cmd+i: Quickly open the project import window.

Use Copy/Paste

Many places in Reactor support copy and paste to speed up your configuration workflow. For example, you can create a behavior on one component and then copy it to several others. You can also copy and paste in many areas of the tree view, to duplicate constant set tables, variables, and other configuration parts between different layers.

Use Undo/Redo

If you ever get lost in the configurator, don't worry—you can use the undo and redo buttons to revert or restore your previous changes. If you want to create a "checkpoint," use History View to create a tagged version of your config.

Batch Editing Components

The Batch Editor allows you to quickly edit several components at once. To batch edit multiple components, drag a selection across them in the configurator. If the selected components don’t have behaviors yet, the Inspector will offer to create new ones for all of them from the library. Otherwise, you'll see all common options of the selected behaviors to edit them quickly. To edit individually, click the table icon below to open a table view of all selected behaviors.

Using "Load Recent" in the Parameter Reference or Condition Helper Windows

When configuring parameters or conditions, you can quickly recall recent parameter references by clicking the Load Recent button in the top right corner of the window.

SKAARHOJ Glossary

Here you can find an alphabetically ordered list of all terms used in SKAARHOJ products that might need additional information.

Behavior

A behavior in Reactor defines how a hardware component should behave. It consists of Actions, and Feedbacks that enable you to define how the Parameter is interacted with and how it is displayed on your component (button, display, fader, etc.). Additionally, there are templates for the settings of a behavior. (See Behaviors)

Blue Pill

Blue Pill is the the platform or "brain" of most modern SKAARHOJ products. As the successor to our legendary Unisketch products, it packs a full Linux operating system into a tiny package and enables control of many devices. Blue Pill Server is a product containing only this brain alone, while most of our outer products ship with the Blue Pill "brain" inside.

Constant

A Constant is a static piece of configuration. Constants can have different types, like String, Number, Color or even IOReference (Parameter). They can either be defined directly in a Behavior (Behavior Constants) or come from a Settings Table.

Device Core

A device core is a package that can be installed on a Blue Pill device. It acts like a driver that allows Reactor to communicate with your broadcast and AV devices using different protocols.

Device Collection

The Device Collection is a file storing all configurations of the devices that Reactor connects to. (See Projects)

devicecore-connector

The devicecore-connector is a tool that allows one Blue Pill device to share its device cores with other Blue Pill devices on the network.

Hardware Component (HWC)

Hardware Components are input or output components on SKAARHOJ panels, such as buttons, displays, faders, encoders, and more. (See Components)

hardware-manager

A package running on your Blue Pill devices that communicates with the actual buttons, displays, faders, and encoders of your controller. It connects to Reactor or can expose the controller as a Raw Panel device on the network for external control.

IO Reference (IOref)

Same as Parameter.

LinkID

A LinkID is a reference to a different layer configuration file. It can be used inside the tree to include sub-configurations.

Master Behavior

Same as Template Behavior (or Settings Template). Originally named after "Master Slides" in presentation programs like Apple Keynote or PowerPoint.

Panel Collection

The Panel Collection is a file storing all configurations of panels and Raw Panel devices that Reactor connects to. (See Projects)

Parameter (IO Reference)

A text string used to address any kind of parameter inside Reactor. (See Parameter Reference)

Raw Panel

Raw Panel is the protocol that Reactor uses to communicate with panels and controllers. It has different protocol variants. Learn more on the wiki.

Reactor

The main application running on your Blue Pill device, connecting panels to devices using configurations.

Settings Table (Constant Set)

A Settings Table is a table in the configuration. It can be used to store settings available on the Home Screen and to generate layers, behaviors, and virtual triggers based on its table rows. It's also called a Constant Set.

Template Behavior

A Template Behavior is used to quickly configure a behavior in Reactor for a given use case. (See Behaviors -> Changing Template Behavior)

system-manager

System Manager is the main package running on every Blue Pill device. It provides access to system configuration using the web interface, handles WiFi, logging, package updates, and all other system-related tasks.

Variable

A variable in Reactor is used to store information like the current menu page. (See Learn more on the wiki).