Routers

Clicking on the Routers link in the navigation bar will present a list of routers in the system:

Pathfinder Core PRO currently supports:

• Axia Audio Routers

• Axia GPIO Routers

• Imagine Routers

• Virtual Routers

• Sap Property Routers

The Axia Audio Router and Axia GPIO Router are automatically generated based on devices discovered in the system. These two routers will always be in the system and may not be removed. Imagine Routers, Virtual Routers, and Sap Property Routers may be created and removed from the Routers page.

Clicking on the Details link for any router will present a new screen with the routing status of the router:

This screen has three tabs on the top: Points, Routes, and XY.

The Points Tab

The Points tab simply lists sources and destinations in the router along with relevant information for each. The columns in each list are broken into two major sections:

1. Source/Destination: Details related directly to the source or destination such as the source’s name, Livewire channel, and availability.

2. Host: Information about the host device where a source or destination resides.

Source/Destination Columns

Host Columns

Since these lists can contain many entries, the search box can be used to narrow the list.

For users that have administrative rights to the router, some additional configuration tools may also be present depending on the type of router. For example, when viewing the Axia Audio router, a button will be present for adding AES67 sources to the router. In the Virtual router, controls will exist for adding additional virtual sources and destinations to the router. These additional controls will be discussed below under the section for each router type.

The Routes Tab

The Routes tab displays the current source-to-destination routing of the router.

Again, this screen is divided into two sides. The source information for each active route is on the left, and the destination information is on the right. The columns display information about each active route:

Source Columns

Destination Columns

Route Changes

Route changes may be made from the Routes tab by either:

• Selecting an entry in the routing list and clicking Change Route

• Double-clicking on an entry in the routing list

Either of these actions will present a dialog with a list of sources that may be assigned to the currently selected destination:

On the Select Source dialog, select the source in the source list and click Take to change the route or double-click on a source in the source list.

Click Cancel to exit the route selection dialog without making changes

Since this list can contain many entries, the search box can be used to narrow the list.

The search filter can persist as you navigate between pages so if you return to the route page and are not seeing sources or destinations that you expect to find, check to see if there is a search filter on the list.

Important Note: A Source will not be available in the Routes list if it is not routed to anything. It will be present in the Take list when you go to make a change as well as in the Points tab under sources, but the search function is only searching data that is in the list. If the source is not routed to any destination, it is not in the routes list because it is not involved in any active route.

Locking

Each route (destination) in a router can be Unlocked, Locked, or SystemLocked.

The lock state is represented by an icon in the Router’s Details table:

System Locked (except for virtual routers described below) indicates that the device itself does not allow route changes to be made on that IO. This is typically seen with console faders where source changes must be accomplished via a source profile load rather than a route change.

Important Note: Other than system locks, locking and unlocking is a Pathfinder state and does not actually change anything in the equipment as Axia equipment does not have lock parameters. Therefore, a locked route in Pathfinder Core PRO could still be changed by the device’s web page.

Locking or unlocking a route is as simple as clicking on the Destinations icon in the route list. Locked routes must be unlocked before they can be changed. In addition, it is possible to define whether a user has permission to change route locks. When defining a user, a field now exists to configure this:

Checking the Can Lock Routes checkbox will grant this user permissions to lock and unlock routes. This allows an Administrator to lock routes and make them unchangeable by normal users.

The Route locks do not apply option is reserved for future development.

Important Note: A virtual destination is comprised of one or more base destinations from other routers. If you lock a virtual destination, it will not lock the underlying base destination. This is by design and allows an Administrator to create a general user router with locked destinations and an engineering router where those same destinations are unlocked. However, if the base point becomes locked, then the virtual destination will display as system locked and the lock can only be removed by unlocking the lock on the base point. In the case where a virtual destination has multiple base points, the locking of any of the base points results in the entire virtual destination becoming system locked.

The fact that locking a virtual destination does not lock its underlying base point is different from how previous versions of Pathfinder worked.

The XY Tab

The XY tab presents an XY grid which allows the user to graphically make route changes. This tab also mirrors the functionality of the XY component available in HTML5 user panels.

Router Types

Axia Audio Router

The Axia Audio Router is created automatically by the system. As devices are discovered or manually added to the system, they are analyzed to determine what audio sources and destinations they provide, and those sources and destinations are automatically loaded into this router.

When you use this router to make a route change, Pathfinder Core PRO is reaching out into the destination device and sending it a command to change the source assigned to that destination. This happens in much the same way as you could make the change from the device’s web page except that you can see all of the audio IOs in one location with Pathfinder Core PRO. Pathfinder Core PRO can also execute scene changes where it can make hundreds of route changes across many devices at once.

You may notice in the points tab that some sources will carry an IP Address of 255.255.255.255:93, have nothing in the host name column, and have “To:” at the start of their Name.

These sources are Axia Backfeeds generated by the mixing engines. They are not assigned a specific host because they are the one and only type of source that can dynamically change which device (Engine) is currently hosting them so they do not have a formal home. To learn more about Axia Backfeeds, see any of the Axia Mixing Console manuals.

The points tab of an Axia Audio Router will also have an Add AES67 Source button. Clicking this button will present a dialog for adding AES67 sources to the system.

Type the name and description by which the source will be identified in the system in the Source Name and Description fields. The AES67 specification allows for sources to be defined using a Unicast/Sip or multicast address format. The information required to define the source is different depending on the selected format and so different fields will be present depending on which definition you select. The example above shows the unicast method. Define the number and the host IP address required to define the Sip path. The resulting address field will automatically fill with the address required for this source based on these parameters.

If you select the multicast option, the required fields will change:

In this case, fill in the multicast IP address and adjust the other parameters to reflect the AES67 source settings, then click add to add the source.

To add a range of multicast aes67 addresses rather than having to add each one at a time, the Multicast IP field will have a second field indicating the number of ios to add. By default x1 will be selected indicating only one new source will be added. Changing the x parameter to a larger number (say 255), will loop though that many ios incrementing the multicast ip and adding an underscore and number to the source name, adding them into the router.

Once added, you will notice that in the list of points AES67 sources will have a minus icon to allow deletion of the source and an edit field to return to the editing dialog shown above.

Once these sources are added to the router, Pathfinder Core PRO can instruct any Axia device destination that supports AES67 streams to receive a specific AES67 stream in the same way as normal Axia route changes are made.

Axia GPIO Router

The Axia GPIO Router is very similar to the Axia Audio Router. As devices get discovered which have GPIO ports, those ports are added to this router. And in a similar fashion to the Axia Audio Router, when you make route changes, Pathfinder Core PRO is reaching into the destination node and sending it a command which tells a specific GPO on that device to follow the GPIs of the selected source device and port. Due to the nature of GPIOs on an Axia network, this routing becomes a little more nuanced and could use some explanation.

There are three ways to route GPIO closures across an Axia network. The Axia GPIO Router in Pathfinder Core PRO only uses one of these methods. It is still important to understand all of the methods however as attempting to use conflicting methods at the same time on a GPIO port can cause erroneous and unpredictable closures.

First, within the Axia device itself, you can assign a channel number to a GPIO port. When you do this, you are creating a special situation where you are telling the port to bind itself to Axia Mixing Console GPIO signals from whatever console currently has loaded that Livewire channel number.

Second, you can assign an IP address and port number of a GPI to a GPO. This is called "snake mode" and it is what the GPIO Router uses to tell a device’s GPOs to mirror another port’s GPIs. Therefore, when you make a route change in the Pathfinder Axia GPIO Router from Node 1 Port 1 to Node 2 Port 4, any GPI closures on Node 1 Port 1, will be mirrored as GPOs in Node 2 Port 4. These route changes can also be updated dynamically, just as with any other router.

The third way that GPIOs can be used is to leave both the Livewire channel number and the routing assignment unassigned, then directly trip the closures using Pathfinder’s (or some other automation system’s) event system by sending closure commands to the device.

The reason it is important to understand these three methods of GPIO closures is that it is possible to do multiples of them at the same time which is occasionally useful but more often just a mistake. For example, we often see users who think that the GPIO ports should have a Livewire channel number and so just arbitrarily assign them. This can lead to a situation where the user has created Pathfinder events to make and respond to changes on those ports, but those same ports are also being fired by changes on the mixing console causing confusion and generating calls to Axia Support. It is important to first understand how you intend to use a given GPIO port then configure it correctly for that task.

Imagine Logical Router

To add an Imagine Router into Pathfinder Core PRO, you first must add the Imagine Device to the Devices list. In Devices, click Add, type the IP Address, and select Imagine LRC from the Investigation Type drop-down list.

Once the device has been successfully added, click on the Routers tab and click Add a new Router.

Imagine routers have multiple levels and Pathfinder Core PRO can control full routes that route all levels at once by adding the  level. Any given breakaway level may also be added separately. Or, both may be added in different routers. This allows routes that should target all levels to be made on the router with the All target and routes of individual breakaway levels to be made on the breakaway routers.

Once added, the router will discover the IOs made available by the selected level and routes may be manipulated in the same way as other routers in the system

Virtual Routers

Virtual routers are a special kind of router. You can think of a virtual router as a way to make a subset of routes you wish a specific user to use. For example, you could create a router that only contains the routes from the Axia Audio Router that are related to a specific studio. Or you could create a router that only contains the routes that are relevant to the final air chains. This allows you to create purpose-driven routers that display only the routes that are relevant to a specific set of tasks and are therefore much easier to navigate than browsing every source and destination on the network.

However, virtual routers can also go much deeper than just subsets of routes. For any specific virtual source or destination, you can also associate multiple real sources or destinations with that virtual source. That sounds complicated but is actually relatively simple and extremely powerful.

For example, let’s say that every time you route a specific Audio Source to a specific Audio Destination, you also want to route a GPIO source that carries signaling information related to that audio source to a specific GPIO destination. An example of where this might be useful would be switching from a primary automation system to a backup automation system by creating a virtual source that contains both an audio and a GPIO source plus a virtual destination that contains both an audio and a GPIO destination. Now, when you use the virtual router to route that source to the destination, it will tell the underlying audio and GPIO routers to make both routes.

To create a virtual router, click the plus icon on the main routers page.

Provide a name and description for the router and click Add. The router id will autogenerate the next available router id number but can be overridden with your own id number. Be sure to use a unique id that is not already in use by another router.

After clicking Add, the virtual router will appear in the routers list but is currently empty as it does not have any sources or destinations. Click the Details button and select the Points tab.

The easiest way to populate a virtual router is to import some sources and destinations from a real router. In this case, we are going to select the Axia Audio Router from the import drop-down and then click Import Sources. You will then be presented with a list of importable sources.

Click on the sources you wish to import (Shift-click to select a range) then click the Import button. Repeat the procedure with the Import Destinations button to import additional destinations into the virtual router. Note that in general, you will leave the target id at -1. This will import the IOs to the end of the router. Setting a number other than -1 will try to import the new IOs at the number selected. This will fail if there are not enough open numbers at the target id to support the number of selected IOs.

At this point, you have a virtual router with only the sources and destinations you want available. This router can then be made available as the only router certain users have access to by using the user rights section, or it can be used to easily see and change certain critical routes without viewing the entire Audio router.

However, let’s dig a little deeper into each individual virtual IO. If you click the Edit link on one of the imported virtual sources, you will be presented with more details about the virtual source.

By default, when you import a source the name and description fields of the virtual source inherit the name of the imported source. But you can change this to any name or description you want using the name and description field. The Base Io Package allows you to define which real sources are a part of this virtual source. As mentioned earlier, it is possible to tie multiple sources together into a single virtual source package. For example, we could select the Gpio router from the Import From dialog, click Import, then select a gpio source to include in this package.

The Move Up, Move Down, and Renumber buttons allow you to change the order of the sources in the virtual source package. Once applied, this virtual source now has both a gpio and audio source and so routing that virtual source to a virtual destination will attempt to make both a gpio and audio route change underneath. The same process can be used to edit and manipulate the virtual destinations.

The Points tab on the virtual router also includes a Plus icon for manually adding virtual sources and destinations and a Minus icon for deleting a virtual source or destination from the router.

Deeper Tech: Packaging

For those who are interested in what happens under the hood with virtual routers, this section is for you. Every virtual source or destination is a package. Within that package is a list of pointers to real sources or destinations. When you make a route change, the system does a number of things.

First, it attempts to organize the package according to the IO types of the pointers in both the source and destination package. For example, it will lump all of the GPIO points together and all of the Audio points together in each package. Then it will try to make one to one routes based on the order of the routes in the package.

This also allows you to lump multiple Audio sources and destinations into a single package. For example, if you were using some sort of immersive sound configuration that required multiple channels of audio (7.1, 22.2) to be routed at once, you could package all of the sources together into a virtual source package and all of the destinations together into a virtual destination package. When the virtual route is made, Pathfinder Core PRO will step through each line in the source package and try to apply it to the same line in the destination package in the order which they exist in the package. If the count in the source and destination packages does not match, the system will go as far as it can to create the matches. For example, if the source package has 1 source and the destination package has 2 destinations, only the first destination will get a route. If the source package has 2 sources and the destination package only has a single destination then only the first source will get applied anywhere.

In the same fashion, the state of virtual routes gets updated automatically as base routes in the packages change. If an audio route changes and the source and/or destination exists in a virtual router, an analysis is done to determine if the current route states of any of the source packages match what would happen if the source were applied to the destination. If they do, the virtual route is updated to reflect that source as the current route. If multiple source packages match the destination, then the first one with the most matches is displayed as the currently routed source.

If no source package matches a destination package, the route may have two other states. The first is “None”, which means that none of the destination package's destinations are assigned to anything. The other state is “Other”, which means that some of the destination package’s destinations have some route applied to them but it does not match up with any of the source packages in the virtual router. This explicitly displays a differentiation between a destination that is cleared and one that might be in use in some fashion, but not one that the virtual router can represent given its existing configuration.

IO Ordering – Move Up/Down and Push Up/Down

The virtual router page also has a block of controls used for manipulating the order of the IOs in the router. These controls are only available to Administrative users. These buttons effectively alter the number of the IO in the virtual router. Since changing the IO numbering of a virtual router can have deeper consequences if the IOs are already in use by Logic Flows or device emulators, these buttons must be enabled by manually selecting the Enable Push/Move checkbox in order to prevent accidental changes.

It is recommended to sort by Port when using this feature as it manipulates up and down based on the port number and not the sort order. This is a design tool to create specific numbering for the virtual IOs and is most useful when those IOs will be exposed to emulated routing protocols that expect a number to be assigned to each IO.

Move Up – moves the IO up in the router effectively decreasing its IO number and swapping with its lower next-door neighbor if necessary.

Move Down – moves the IO down in the router effectively increasing its IO number and swapping with its higher next-door neighbor if necessary.

Push Up - moves the IO up in the router effectively decreasing its IO number and pushing any lower-numbered IOs it runs into up as well decreasing their numbers until it reaches a hole in the numbering or 0.

Push Down - moves the IO down in the router effectively increasing its IO number and pushing any higher-numbered IOs it runs into down as well increasing their numbers until it reaches a hole in the numbering or the highest value in the router.

Sap Property Router

By selecting the Sap Property Router type, any property that can be read from in Pathfinder Core PRO can become a router source and any property that can be written to can become a router destination.

For example, in the legacy Pathfinder Pro it was possible to create a router of individual GPIO pins instead of routing entire ports using the GPIOByPin router. This same functionality can be realized with SapPropertyRouter in Pathfinder Core PRO.

Creating a Sap Property Router

To create a Sap Property Router, browse to the Routers navigation link and click the Plus icon to create a new router.

Select the Sap Property Router from the drop-down list of available Router Types. Click Add to create the new router.

Adding IOs

To add IOs to your new router, click the Details link and then click the Points tab.

Like the virtual router, you will see Import Sources and Import Destinations buttons as well as a Translation button. However, clicking these buttons for this router will display the property selector used in Logic Flows.

In the example above, we are going to select a GPI PinState property.

Type a name and description for the IO (or use the default) and click Select. Repeat for other pins you want as sources, then import the destinations.

Note that if the ports you are using for destinations are on a Livewire driver or Pathfinder Core PRO GPIO node, you can use GPI pins as the destination and route GPI to GPI. When you are done, it might look something like this:

If you go to the Routes tab you will see the destinations with a "take table" of the sources where you can make route changes.

In this example, GPI pin 5 has been routed to GPO pin 1. Therefore, any closures that take place on pin 5 will be replicated on pin 1.

Translation Patterns

Clicking the Translation button on the Points tab will open the translation pattern used for any values that pass from the source property to the routed destination properties. This is a single translation pattern that is used between the source values and destination values.

In the example above, the translation pattern is *=*. Using this pattern, a pin low on the source side will cause a pin low on all destinations to which the source is routed. By changing this translation to l=h and h=l, lows on the source would generate highs on any destination to which that source was routed.

Translation patterns may be applied to other properties. Applying a translation pattern of l=5000 to the Pulse state would force the output to go low for 5000ms each time the input went low. Without defining a h= value, nothing would happen when the input went high.

While we could achieve similar results with Logic Flows, configuring a router allows the start point of a flow to change dynamically. For example, suppose we have a Vmixer assigned to each air chain with channel 1 representing the feed from the studio console. There is a GPI pin in the studio which turns the Vmix channel on. This is simple to accomplish with a Logic Flow:

What if we have 5 studios and any one of them could be assigned to the air chain? Using Logic Flows this becomes much more complex because we must build flows for each studio-to-airchain variation. However, this becomes easy with a property router. On the source side of the router we select the GpiPinState property, and on the destination side we select all airchain Vmix IN state properties:

Once the items are selected, we can change the translation to:

Now when we route a studio pin to the airchain Vmix, the low from the studio will control the Vmix state of whichever airchain that studio happens to be routed to.

We can extend this example by using a virtual router where the virtual source package includes the audio console program buss audio source and the pin source from the SapProperty router, and the destination package includes the Vmix channel input audio destination and the Vmix state property from the property router.

These signals get married together such that a single virtual route change will switch both audio and signaling seamlessly. That virtual router can then be controlled by a third-party application using something like Probel without that application needing to know that we are actually switching numerous things under the hood. This opens up a whole new world of routing possibilities.

Another interesting example uses many of the new features described above. What if we wanted to route a TCP stream of song data to different destinations depending on what is currently on the air? We could create generic device emulators for each destination and each song data source. Using the regex capability, we could then add a watcher to the emulators on the source side that looks like:

Regex.Match((?s).*)

This will match any data coming in. Then, we create a new property router and choose the watcher TranslationValues for the soruces. For the destinations, we select the ToSend property of the destination generic emulators. This will essentially pass any data that comes into the source emulator to the output of destinations to which that source is routed. Then we could also marry those points into the air chain virtual router such that audio, studio pin to Vmix state, and songdata are all married together as a single virtual route.

Another possibility might be to route memory slots. Or, we could use the duration regex example above to capture different satellite duration data as source points in a router that then gets passed on to countdown clocks.

The point is, you can now route anything Pathfinder knows about.

In each example above, all sources and destinations in a given property router are of the same type. While this is not strictly required, it is usually good practice. Once you start mixing IO property types in the same router’s sources or destinations, the translation table can become non-intuitive and it is possible to output the wrong data to devices.

As there is no route state in the equipment for this type of routing, in order to retain the route state between restarts, this router must store all route changes (not the values transitioning through the routes) to the backing storage. In the case of the fanless engine which uses compact flash for this storage, we have implemented some protections to reduce the write cycles, though it is not recommended to make recursive millisecond route changes on Property routers if it can be avoided; for example, a rotation circuit that continuously loops through changing property routes. This is less of a concern with the R2 platform which uses SSD and the VM version.