These instruction sets apply to WideOrbit Automation for Radio versions 2.x to 3.7.x. Newer versions are likely similar.
WideOrbit can address SLIO’s on blades via the Wheatnet ACI. For this setup you will need WO automation for Radio Device Server setup and installed on a PC with access to the Wheatnet ethernet network. If you have a machine running the IP driver, you likely already have this in place. If not, then DeviceServer might need to be installed on a seperate PC that is connected and addressed to both the Wheatnet and WideOrbit Audio Networks. This can be the WideOrbit Central Server computer, or a utility computer if needed.
Typically, if you are running the Wheatnet IP Driver, we’ll want to use DeviceServer on that machine to make the connection to the Wheatnet network as that connection already exists.
To see if DeviceServer is installed and running on the PC in question, Check Windows Services and look for a service called WOAR DS. If that service is present then DeviceServer is installed. If it is not running, go ahead and start the service. Once started, then proceed to the next steps.
Access the WideOrbit Automation for Radio Web Configuration GUI. You must log into WideOrbit’s UI with a user that has privileges to configure and modify Devices.
Click on the “Devices” link on the left hand side.
Add the Device Server (This is the Machine running Device Server)
DeviceServer name = Friendly or Label Name for this instance of Device Server
Hostname = the Host Name of the PC running DeviceServer. (note you can use IP address however this can cause some issues in older versions of WideOrbit Automation for Radio).
Port = This is the TCP/IP Port (socket) that DeviceServer communicates with CentralServer on. Default is 9999. It is not recommended to change this unless directed to by WideOrbit support.
Click Add when done to save.
Now that we’ve defined the DeviceServer Instance, we need to define the IP address and Port of the BLADE that we want to use for it’s SLIO’s. This is done on the PORTS Tab in the Devices Config.
Here it is recommended to use the IP Address of the BLADE and NOT a HostName.
In our example, we enter the IP address of the NIC assigned to the IP driver that we want to use to assign the console logic for.
Port = 55776 This is the ACI port for Wheatnet Blade Systems.
Timeout value = 5000 ms (5s) max setting recommended.
Click Add when done to save.
Now to define the “Device” to WideOrbit in the Devices Tab.
Click Add Device to get started.
Use the DeviceServer Instance that we just created.
Use the TCP/IP Port we setup for that DeviceServer to map this instance.
Select Wheatstone as the Manufacturer.
Select Blade as the Type.
Click Next.
On the Next page fill out the details:
Select PC Driver as Blade Type
Fader Count – Defaults at 12 and is not used in this instance.
Softpin Count – This is the number of SLIO’s on your PC Blade
Timeout – This is a hearbeat setting between WideOrbit and Wheatnet. Leave the default value here.
GPI and GPO Count – This determines the grid size in WideOrbit for both the GPI and GPO sections after the device is saved. The values on each of these should match your SLIO Count on this Blade.
Click Add to save this device.
After a few seconds this will create a device instance in WO automation for this blade.
Note the Device may appear greyed out. This is normal, and even though it appears this way, the connection is working fine. Typically a browser refresh will cause the device to not be greyed out.
If you get an error message, you will need to contact WO Support to resolve.
A NOTE about how SLIO’s are treated in WideOrbit.
WideOrbit was originally developed around the concept of a Matrix Switcher like the ones common in older studio installations. The Matrix Switchers typically had GPI and GPO logic ports on them and they were addressed as seperate spaces in the WideOrbit Software. In order to maintain compatibility with these older devices, when you look at WO’s GPI and GPO Grids, keep in Mind the following, since with Wheatnet SLIO’s can be either a Input or an Output, depending on the use….so from the WideOrbit perspective – If you use GPO #1 -5 in the WO Grid, then that means GPI 1-5 in the GPI Grid cannot be used, because by defining GPO 1-5 in the WO screen, means you are using SLIO 1-5 in Wheatnet. Conversely, if you use GPI #6 then GPO #6 in WO cannot be used as the SLIO#6 will be used to send logic to WO not receive logic.
Some customers have implemented a scheme to keep track of this. Say your blade has 64 SLIO’s. For the purpose of integrating with WO, you could scheme that 1-32 are Inputs from WO, and 33 – 64 are Outputs to WO (WO GPI’s). This is not mandatory, but it can help you keep track of what is what.
Ok, so now WO needs to be setup to send GPO to Wheatnet. Each Channel can have up to three actions. Fire Before Play (ch on) Fire After Play (ch off) and Fire when next(Tally). Typically the WideOrbit Stack is rotating through three or more channels and on each rotation through the audio these “PlayChannelActions” can cause the console channels to follow as it plays on.
In order to do this we need to define the output pins (GPO’s – SLIO) to use for this. With Wheatnet this is easy.
Select 1 GPO Pin in WO and Label it. Say CH1 LOGIC. Save the configuration in the Web GUI.
In the Workstation Launcher application –
Click on the DeviceServer Tab.
Add the Device Server Instance we created earlier in the Web GUI.
Click the PlayChannelActions Button
Define the Station that will use this logic, and the Device Server and Device Name and the Audio Channel this logic is for. In our case we only have 1, but remember WideOrbit is 0 based so it is Audio Device 0.
In the Fire Before Play Setup
Note these must match what is in the CentralServer application exactly and is case sensitive.
Now to configure the actions –
Fire Before Play – Use our WO GPO PIN Label we created ealier CH1 LOGIC
Use the “Latch” function and State = ON
Fire After Play – Use our same Label CH1 LOGIC
Use the “Latch” function and State = OFF
Fire When Next – Use our Same Label CH1 LOGIC
Click Ok, Save and Launch WideOrbit Automation for Radio –
Next we need to go into Wheatnet Navigator and assign these SLIO’s to the Audio Sources from the Driver and map their functions.
In Navigator find the PC Blade you are working with.
Select the Sources Tab
Select the First Output Source (You can rename it here if you would like) and Click Edit Button.
Now Select the LIO Info Tab
Use the Pulse Function.
The screen should show no LIO’s mapped to this signal. We need to now add the functions. To do so, click Add.
The “Add” button will be greyed out if the signal is connected anywhere in the system. This is indicated in the lower left of the Edit dialog box. It the signal is not connected you will see “Signal is not connected”. If the signal is connected you will see “Signal is connected”. If it is the latter, you will need to go to the crosspoint and disconnect that source from any destinations. You will want to make a note of what destinations may be using this source. This will allow you to re-establish those connections once you are done.
Remember that the SLIO # is equated to the GPO# in WO’s Device configuration grid. So for our purposes, we select SLIO # to match and Select it as an Input, and Function is assigned Remote On.
We don’t need another SLIO for Off as WO is setup to Latch Off that Same SLIO in it’s Fire after Play command.
Setting up a Machine Start to WO for WO’s PinActions function(s)
WO has a couple of different playback modules that can be started by Wheatnet remotely (from the console) using SLIO’s. This can be done from the Channel On buttons or spare buttons on the console. Note, that if you use a spare button on the console you will need to also configure that button to fire an SLIO using the console gui.
WO’s Stack typically takes one GPI to cause it to advance to the next item. (In WO terms it’s a Start Next, Advance Stack or Start Stack function) WO has two scripts one that will change the mode if starting from Manual to Auto, and the other just advances the stack without chaning the mode. Consult your WO user Manual or contact WO support for details on which script to use for your application.
So, now back over in the WO web config GUI, in our same Device we created earlier, we need to expand the GPI grid. Pin Actions only work using GPI’s defined here. Remember if you have used GPO 1 below to send Logic to Wheatnet, you need to avoid using it here. Keeping with the idea above that we split the SLIO range of 64 in half, and used 1-32 as GPO’s, then we can start with GPI #33 in WO as a first input pin.
Enter a label name in the grid to define the GPI for PlayChannelActions. (Note you may have more than one defined for the STACK, and or Player Widgets.) In our example here, let’s say we have three audio channels used to playback the WO Stack Widget. We have these three channels assigned to three console faders. We want to be able to press any of the ON buttons of these three channels to Advance / Start the Stack. So here I will use three GPO’s that if any one is received will do the same function. So we’ll label these STACK1, STACK2, STACK3 to GPI 33, 34, and 35 Respectively.
Once entered click Save to commit the labels to WO’s database.
Now back to the WO Workstation, get back to the Launcher Application, and select the Devices Tab. Now click on PinActions Button.
In the PinActions Dialogue define the Device/Device Server and Pin Name (Label we just created in the web GUI) remembering that the case and syntax have to match exactly. In the Parameters section, add either AdvanceStack.js or StartStack.js (Again here, WO manual or support can help you decide which to choose.) Because we want the Stack to start from stopped state and change to Auto after it starts, we are going to choose StartStack.js
Note that syntax in this field is also case sensitive.
Click apply and OK. Now repeat for the two other PinActions that we want, again using the StartStack.js parameter.
Once done, launch WO AFR Workstation application.
Now back to Wheatnet Navigator.
Select the PC Blade that we are working with. Select the Sources Tab, and then Select the First Signal and select Edit. Then Select the LIO Info Tab.
Now click Add.
If Add is greyed out, it will indicate that the signal is connected somewhere in the system. You must disconnect the signal first in order to make changes.
Select SLIO #33, type is output, and Function is Machine Start.
Apply and OK to save.
Repeat for the other two Source Signals moving to 34 and 35 respectively.
One other thing to check in the Surface GUI is the Machine Start setting to ensure that when the Remote On function happens, we don’t get into a loop of the channel turning on and also sending the Machine Start causing the automation to rapid fire through its players.
For example, in the LXE GUI, you would want these turned off on User Options:
Other consoles, like the DMX, L Series, and IP Series will have a checkbox that says “No LIO with RMT.” You should check that to block an endless loop.
Also, on the LXE GUI, remember to enable Machine Start for the On button, or else your remote starts will not work. (Only the LXE will have this feature.) Go to Module Layout, Click on the first On button. Check Mach Start LIO.
Then right click the channel strip and Copy Input Module.
Then right click the next channel strip and choose Paste All Input Modules. Apply!
Variations –
The setup is similar for the WO player Widget Decks. Each Deck will have some defined logic for Start/Pause, and Stop/Eject. The setup is the same, using an at least two SLIO’s for the functions.
You would need an SLIO for Each Deck in the Widget that you wanted to Control using Machine Starts.