IO References
In this article we explain the internal structure, of the IOReference string.
This willdocumentation helphas you,moved, ifsee youhere: to find the correct modifiers to use in Configuration tab, and when using the JSON editor
What is an IO Reference (aka IOref aka Parameter)?
An IO Reference is a unified text reference to a data point that can be read and/or written. This data point might represent a device parameter, a variable within the Reactor, or a read-only constant. A device parameter allows users to both set and fetch its value. In contrast, a variable within Reactor can also be adjusted and retrieved, whereas a constant can only be read.
Reactor employs IO References extensively to facilitate data-driven configurations. These configurations are used for a range of functions, including enabling or disabling features, displaying information, defining button colors in response to data, and identifying the next value for a parameter.
In many ways, IO References are similar to URLs as encountered on websites, providing a consistent method for accessing and manipulating data.
Examples
Datatypes
IO References can encapsulate different types of data such as strings, integers, floating point numbers, and booleans. For booleans, the values are represented as the strings "true" or "false".3_configuration/ioreference.html
In essence, every IO Reference is treated as a one-dimensional array, allowing for the possibility of holding multiple values or even none at all. For instance, a constant might contain anywhere from zero to many values, though typically it holds a single value. When interacting with Device Cores, single values are exclusively employed. Variables usually operate with single values too but may occasionally use multiple values. This multi-value support is inherently built into the IO Reference system.
IO Reference characters and structure
IO Reference strings shall only contain the characters [a-zA-Z0-9_,\.-:/{}] where":" and "/" are generally used to tokenize the IO ReferenceCurly braces, {}, are used to nest other IO References where allowed. Encapsulation is not always necessary, but if the nested IO Reference contains the same characters as used for tokenization, it will be necessary. The safe and consistent choice would be to always encapsulate.[] is a part of literal values when they contain multiple values in the set.
IO References are generally tokenized using a combination of colons and forward slashes. Specifically, an IO Reference's basic type is always indicated by a prefix that precedes the first colon in the string. If there's no colon, it's considered a literal value (or a set thereof). The different types are outlined below.
Literal values
Literal values, such as "3", "true", or "page1", are utilized to assign a fixed value instead of referencing another data source.
Frequently, it may be desirable to define literal values as sets with multiple elements. In such cases, these values are enclosed in brackets, with individual values separated by commas, for example, "[red, green, blue]".
Format: Any IO Reference without a colon is categorized as a literal value.
|
Strings ("String")
The "String:" prefix allows complex strings to be treated as literal values, particularly when they contain special characters. Without this prefix, these strings might otherwise be parsed due to the presence of such characters.
Format: String:[Value]
Variables ("Var")
Variables in Reactor are used to hold data that can be manipulated. You can think of them as containers that store information. Their value can be changed, and they can be reused many times at different places in a configuration. The purpose of a variable is never predefined by Reactor but depends on how it's being used in the configuration.
Usually variable either spans an integer range (eg. from -10 to 10) or has specific options with names (eg. "page1", "page2", "page3" with the names "Home", "Setup", "Color")
Format: Var:[Variable reference]:[Mod 1]:[Mod 2]:...:[Mod n]
Examples
Modifiers
See the General Modifiers table
Device Cores ("DC")
IO References that are prefixed with "DC:" correspond to parameters in devices that are managed by device cores. These are the devices that have been added to Reactors current project for control purposes and/or to serve as data sources.
Format: DC:[Seg 0]/[Seg 1]/[Seg 2]/[Seg 3]/[Seg 4]/[Seg 5]/:[Mod 1]:[Mod 2]:...:[Mod n]
The string following "DC:" is divided by "/", with each resulting segment signifying the following:
Segment 0: Device Core reference, eg "bmd-atem"Segment 1: Device Index, aka Device ID (IO Reference, optionally encapsulated in {})Segment 2: Parameter referenceSegment 3-5: Parameter Dimensions (0-3 , depends on parameter). (IO References, optionally encapsulated in {})
Modifiers
See the General Modifiers table
Examples
| |
Constant Sets ("Const")
Reactor's constants are unchangeable values embedded in the configuration code, used for various purposes within the configuration. Unlike variables, constants can only be modified by altering the configuration.
Constant Sets in Reactor are essentially tables of related constants. Each row forms a set of constant values, and columns represent different constants within these sets. They can be utilized for a variety of functions, from setting switcher inputs to configuring a PTZ controller's camera selector. Even simpler uses might include single-row constant sets for configuring specific aspects of a configuration, such as the number of cameras on a page.
Format: Const:[Seg 0]/[Seg 1]/[Seg 2]/
The string following "Const:" is divided by "/", with each resulting segment signifying the following:
Segment 0: Constant Set reference. The name of the closest constant set in the layer tree.Segment 1: Constant Set row index (IO Reference, optionally encapsulated in {})Segment 2: Constant Name
Modifiers
See the General Modifiers table
Examples
Behaviors ("Behavior")
Behaviors dictate how a controller's hardware component typically interacts, including the actions it can execute on devices and other IO References, as well as how system feedback is displayed on its screens and LEDs.
IO References of the "Behavior" type facilitates reading and writing of the behavior aspects, which are often the context of an IO Reference.
Format: Behavior:[Seg 0]/[Seg 0a]:[Seg 1]:...[Seg n]
The string following "Behavior:" is divided by ":", with each resulting segment signifying the following:
Segment 0: The sub-type. This string value is further divided by "/" to provide a further refinement of the sub-type.Segment 1-n: Depends on the sub-type. See the overview below
Basic Info
This is basic info about the behavior:
| ||
| ||
|
Access to the Behaviors IO Reference ("IOReference" sub-type)
Behaviors usually modify a single parameter - a single IO Reference - in a device or within Reactor. To simplify this, behaviors have a master IO Reference field set by the user, which can be referred to throughout the behavior's configuration as "Behavior:IOReference". For example, if the behavior's IO Reference is set as "DC:bmd-atem/4/AuxSource/2/", "Behavior:IOReference" can be used as a substitute anywhere within the behavior where IO References are applicable. If the label of a value is needed instead, "Behavior:IOReference:Current:Name" serves the same function as "DC:bmd-atem/4/AuxSource/2/:Current:Name".
With "Behavior:IOReference", the "main" IO Reference is derived from the master IO Reference, while modifiers in segments 1-n are taken from "Behavior:IOReference".
Examples
For these example, assume that the IO Reference of the behavior is "Var:Menu" with the name "Page" and with the current value being "page1" with the label "Background"
| |
| |
|
Script State ("Script" sub-type)
These are read and write registers of a behaviors script.
| ||
|
Last Event ("LastEvent" sub-type)
These are read registers of the last event received by the behavior.
|
| |
| ||
|
| |
|
| |
|
| |
|
| |
|
|
Event Handlers ("Event" sub-type)
These registers are associated with the various event handlers that can be established for a behavior. The term "eventHandlerKey" in the subsequent table refers to the specific event handler's name being referred to.
| ||
Behavior Constants ("Const" sub-type)
Sub Behaviors ("Sub" sub-type)
(Future - may not be in Reactor yet or ever...)
Presets ("Preset")
String after "Preset:” is split by “/“ and the parts will mean this:- Index 0: Preset reference (like variables)- Index 1: Command- Index 2: Preset number (IOreference, (Optionally encapsulated in {}))- Index 3: Device Index (IOreference, (Optionally encapsulated in {}))- Index 4-…: Dimensions (After the last trailing slash, if “:” is found the following will be used as modifiers)
Flags ("Flag")
(TODO)
System
System:LockSystem:IPAddress
Reactor
Reactor:ProjectTitle - Current Project titleReactor:ConfigTitle - Current name of root layerReactor:CurrentProject - Allows to trigger a change of projects using SetValueReactor:RestartEngine - Perform a restart of reactors engine, like switching projectsReactor:UptimeFormatted - Uptime since Reactor was started
Reactor:Panels:Connected - Number of connected panels Reactor:Panels:Warnings - Number of panels with warningsReactor:Panels:Unconnected - Number of unconnected panels (errors)Reactor:Panels:LastEvent - Last event as a string, eg. "Down (T)" if a four way buttons top edge was pressed down.Reactor:Panels:LastEventSource - The HWC source of last event, including panel ID, on form "P[panel id]#[HWC id]", for example "P1#43"
Reactor:Devices:Connected - Number of connected devicesReactor:Devices:Warnings - Number of devices with warningsReactor:Devices:Unconnected - Number of unconnected devices (errors)Reactor:Devices/[idx]:Name - Name of devices. idx is just an index.
Reactor:Warnings - Total number of warnings in ReactorReactor:Errors - Total number of errors in Reactor
Panels
String after Panels: is split by “/“ and the parts will mean this:
Index 0: Target of ID: "Canvas", "Panel", "CanvasOfPanel"Canvas/[id]/ - forcing a given canvas id. Normally not usedPanel/[id]/ - forcing a particular panel only. May be used when canvas is not used to represent a coherent panelCanvasOfPanel/[id]/ - normally the one used because Reactor knows the panel ID, but usually desires to target the canvas of the panel(Usual source of id is: Behavior:Panels)
Index 1: ID of target (IOreference, (Optionally encapsulated in {}))Index 2: ParameterSleepTime, minutesDimTime, minutesDisplayBrightness, 0-8LEDBrightness, 0-8GlobalBrightness, 0-8Sleep (binary: "on", "off") - Is reset by the panel when it wakes up again. It's probed once a second, so it can feel a little like a "hold down" functionResetSleepTimer (trigger)Name (read only)Model (read only)
General Modifiers
General modifiers are used by certain IO References due to their shared data source framework. However, not all IO Reference types support or need these modifiers. The table below indicates which primary types - Device Cores (DC), Variables (Var), and Constants (Const) - support these general modifiers.