Warning: This version represents a feature freeze of any new features in the 1.9.x beta branch in preparation for a new release. During the final beta period, only bug fixes will occur in the 1.9.x branch prior to a 1.10 release. Any new feature work will now move to a new 1.11.x beta version.
Due to a special project, we had to add a few features in this version after the initial freeze in 1.9.12.62.
This version adds the ability to override the virtual router's advanced options in each base IO if necessary. Virtual Routers include two advanced options:
Push current source (route) on base io enable - will push the current route state to disabled base ios when they become re-enabled.
Send route changed to disabled destination base ios - will send route changes to disabled base ios if this option is enabled
These two options now also exist on each virtual router's destination base io. By default the parameters on each base IO will be set to Follow which means they will use the overall route advanced settings. But they can be overridden to create different behavior on individual base IOs. This is accomplished either via logic flows or via a new link in the UI. When editing a virtual destination, there is now an edit link for each destination:
Clicking the link will open a dialog where these options can be overridden. The new dialog also presents on option for toggling the base IO disabled state via the UI:
Overriding the router advanced option can be accomplished by changing either of the two options from Follow to the desired enabled or disabled setting. Remember these settings only affect the functionality when the base IO is disabled or returning from disabled to enabled.
As a refresher to the functionality, a disabled base IO will not be considered when evaluating whether a route is active. If the SendRouteToDisabledBaseIO option is enabled, route changes will still be sent to a disabled base IO. If it is disabled, then those changes will not be sent. If the PushRouteChangeOnEnabled option is enabled, the current route value will be sent to the base IO when it becomes re-enabled.
The customer has built a virtual router where each source and destination has multiple layers. A primary and backup audio IO, and a primary and backup metadata IO from a SapProperty signaling router. In this case they do not want a failure of the metadata layer to cause the route state to not be indicated to controlling automation. But they do want to be able to take one of the audio layers offline for maintenance or special situations (like EAS). In this case, the customer can set the router advanced options to:
PushRouteChangeOnEnabled: Enabled
SendRouteToDisabledBaseIo: Disabled
And on the individual destination base IO layers they set:
Disabled: True
PushRouteChangeOnEnabled: Enabled
SendRouteToDisabledBaseIo: Enabled
In this example the metadata IOs are always disabled, but will still receive route changes. This means they will not be considered toward the success state of the audio route, but will be changed anyway. The audio layers are set to the default Follow so will follow the router settings. Therefore an audio layer can be disabled and switched away to something else, and route changes will not affect it, but it will get updated to the correct state when returned. It is important to note that for the PushRouteChangeOnEnabled to work and/or for routes to actually have a route state, at least one layer must be enabled. A SapProperty router can be used as an additional layer that is never disabled to maintain state if needed.
This version adds the ability to disable an audio alarm. In order for downstream logic to maintain its state, disabling an alarm involves fixing it to a specific state regardless of the underlying audio. Therefore the disable options are:
Enabled: Alarm is enabled and works normally based on the audio changes.
AudioPresent: The alarm state is fixed to the audio present state regardless of the underlying audio changes
Silent: The alarm state is fixed to the silent state regardless of the underlying audio changes
Clipping: The alarm state is fixed to the clipping state regardless of the underlying audio changes
In addition to manipulating these states using logic flows, the state is now represented in the audio alarms grid and may be manipulated by editing the alarm:
Clicking the edit link also now has an Enabled drop down in the alarm editor.
Note: The enabled property only affects the AlarmState property. The TimerState and LVL state still function in order to keep track of the correct audio alarm state underneath for the time when the alarm is returned to being enabled.
An additional section has been added to log writer editing for logging scene changes:
Each of the items in the scene section will log changes as described below:
ActivateSceneRequested - logs when a scene activation is requested.
ItemsAreActive - logs each scene item's active state.
ItemsCurrentValue - logs changes to each scene item's current value.
SceneIsActive - logs whether the entire scene is active
SceneState - logs the scene state (Some, None, All, etc.)
