Version 1.9.4.15 Changes

To fully understand the changes in this version it may be useful to review the virtual router base io enable and disable feature described in the manual here.

Send route changes to disabled destination base ios

This version adds an option to Virtual Routers under the advanced button. Navigate to the virtual router details, click the points tab and then click the Advanced button.

By default if a base IO within a virtual router destination package is disabled, route changes are still sent to that base io if the virtual destination's source is changed. This is intentional. The use case described in the manual describes a situation where you wish to take an engine offline for maintenance and still want the routes for that Engine's base io to appear to work as long as the other base ios route successfully even though the device is offline. In that case it does not hurt to also send to the offline engine for the periods of time when it is online during the maintenance session. However, there may be times when you essentially want to fix the base io destination to a source and ignore other route change requests to it. In this case, disabling the base io and setting the "Send route changes to disabled destination base ios" option off may be appropriate. In that case when a new virtual source package is applied to the destination, base io sources that would normally be applied to that disabled base destination will be skipped. Then when the destination base io is reenabled, the current source base ios will either be sent or left in their current state depending on the Push current source (route) on base io enabled option.

Virtual Router Enabled/Disabled logic changes

In previous versions, disabling a base io in a virtual router destination package would conceptually remove the destination from the package for the period of time when it is disabled. This actually caused problems in situations where the destination package contained multiple ios from the same router. For example:

Source A	Destination B
Audio 1	Audio 10
SapProperty 1	SapProperty 10
SapProperty 2	SapProperty 11
SapProperty 3	SapProperty 12

In the example above if each source from source A's package is routed to the corresponding destination in Destination B's package then the system would consider Source A to be routed to Destination B. Now if we disable the SapProperty10 base io the packages end up looking like:

Source A	Destination B
Audio 1	Audio 10
SapProperty 1	SapProperty 11
SapProperty 2	SapProperty 12
SapProperty 3

So now Source A would only be considered routed to Destination B if SapProperty 1 were routed to SapProperty 11 instead of 10. Therefore if prior to disabling anything Source A was successfully routed to Destination B, if you disable the SapProperty 10 destination, the source assignment would switch to other. There is no route in the router that expects SapProperty 1 to be routed to SapProperty11 as a base io. This does not happen if the base ios are from different routers because the packages get organized by router type.

To fix this issue we no longer conceptually remove the base io when it is disabled. Instead we accept any route state as valid to that disabled destination (including None). This effectively allows the destination to show as routed no matter what base io source is routed to that disabled base io, while still allowing the proper alignment of other base ios in the package.

Source A	Destination B
Audio 1	Audio 10
<Any>	SapProperty 10 (Disabled)
SapProperty 2	SapProperty 11
SapProperty 3	SapProperty 12

This creates the desired behavior, but it is a fundamental shift from how this feature worked previously so please report any issues you may encounter.

Note that the descriptions above refer to the logic that decides the current route state. When executing a route change with disabled destinations, a route is either sent to the disabled destination or not based on the "Send route changes to disabled destination base ios" option.

Use case examples

In the original example described in the manual, a source is duplicated in the source package and the destination package contains destinations from 2 different mix engines for redundancy. In this case if you want to take an engine out of service, disable the base io in the destination package for the engine and leave both checkboxes in the Advanced section enabled. This will attempt to send route changes to the disabled engine but accept that they may not be successful. Then when the engine is back online and you re-enable the base io, the current source base ios will get sent to the engine to bring it back to the correct value.

On the other hand if the intent is to create a patch around situation where you are basically temporarily assigning a different io to the base io but you want the logic to pretend the normal source is assigned, it is better to uncheck the "Send route changes to disabled destination base ios option". This will allow you to make route changes while leaving that base destination in a fixed state.

Future Changes

Currently, the system allows you to disable base points in the source package as well as the destination package, but that is rarely useful and so may be hidden or removed in a future version. If you find use cases for this ability, please report them so we can take them into consideration.

Additionally, because the virtual mixing router is based under the hood on a virtual router, the base io enable/disable features are currently exposed and exist in the virtual mixing router but may not work as expected. Again, we are not seeing much of a use case for this capability in Virtual Mixing routers. If you find use cases to the contrary, please let us know. Otherwise we will likely remove or hide those options in a future version.