WideOrbit GPIO Considerations

Updated by Bryan Jones

Scope

This document covers GPIO considerations when using WideOrbit with Axia GPIO. The premise is the same regardless of which actual GPIO that is in use. For example, using GPIO from an Axia IP-Driver, an AudioScience Livewire card, or a physical GPIO node are all the same.

This document is also rather non-specific and could apply to any Radio Automation System. As of this writing, WideOrbit is a prevalent system, and hence we field lots of calls with questions about this.

Description

First, a description of the issue most people face.

Historically, as an industry, we have always interfaced gear to consoles in four, sometimes five ways.

  • On - Turns the channel ON when the device starts.
  • Off - Turns the channel OFF when the device stops.
  • Start - Sends a start command to the device when the channel turns on.
  • Stop - Sends a stop command to the device when the channel turns off.
  • Ready - Turns the ready light (usually the off button) on when the device is ready to play.

Those "devices" we refer to were not automation systems. It was three or four CD players, four or five cart machines, etc. Having this much (what we will call) "channel" logic was necessary. Also (this will become important in a moment), the devices didn't care about their "state." In other words, if your cart machine was playing, and it received a more start logic, it didn't do anything. No more so than the console did anything if it was already ON.

Today, things are VERY different. A single computer replaced all those devices using (on average) three faders on the console. Using the WideOrbit configuration as an example, there are typically three audio channels from what WideOrbit calls the Stack. The Stack is where all the magic happens. The Stack automatically loads the "CDs" and cross fades them, watches the levels, etc. The problem here is all of that "channel" logic that we talked about previously.

The Stack doesn't want (and can't tolerate) a GPIO every time something starts or turns on. The Stack only needs a GPIO to tell it to GO, and if you tell it to GO more than once, it dutifully does.

The issue we see here is that when the Stack turns the channel ON so that the audio will play, it's the same as pressing the ON button. Turn ON = fire a start pulse. That process happens from all three channels in the Stack. The problem comes when we incorrectly map the (old style) channel logic to (more modern) automation logic. This ends up improperly advancing the playlist every time.

So, what do we do about it?

There are as many answers as there are automation systems, and each one is different. Some have separate logic for StartAutomation and StartNext. In other words, if I get a start, and I am already started, don't do anything.

Some will "ignore" a start pulse within some small time window of starting. For example, if I reach up and touch the screen to start the audio, I could assume that a start pulse that comes 25ms later might not be needed or desirable.

Then there is logic for FadeAndGo, FadeToStop, or Stop (which takes it out of automation mode).

We need to make sure that we only map WideOrbit to the Channel logic that we want to use. Generally, this is only the logic to turn the channel ON and OFF but not to use the automatically generated start pulse.

There are also options in our system to "ask" for what you want. In other words, you could send the command FaCH#4 On_State=ON,Start=NO. In which case, you turn the channel ON but suppress the start pule.

MANY ANSWERS.

Consider the following configuration.

Here you see we have audio channel from our Stack of 2601, 2602, and 2603 and the same channels for GPIO. This configuration means that the GPIO on our driver is AUTOMATICALLY going to deliver us that "historical" channel GPIO.

Axia GPIO is predefined by the type of source. Line sources have one set of logic, Microphones another, Phones another, etc.

To use them, we have to "map" these Driver GPIO pins to functions in WideOrbit. This is done using the WideOrbit Device Server and assigning friendly names to those individual pins. The names would be PC_1_ON, PC_2_ON, PC_3_ON, etc. We'll repeat these for off. Note that we are not doing anything with START.

The reason we don't do anything with start is that we don't want to start a channel. We want to start automation and let the automation turn on the channel that is next.

Starting Automation

Enter Pathfinder. Remember I said there are as many options as there are automation systems. Pathfinder is your goto tool for things that are different from the pre-programmed way.

One example might be a set of dedicated, programmable user buttons.

Programable user buttons are offered on all Axia consoles.

You would use Pathfinder to program the button so that when pressed, it would trip a GPIO PIN on the driver. In the WideOrbit device server, we might name that pin "StartAuto." You might program a second button and call it "ModeToggle" (this would switch between auto and manual). Use your imagination here.

In some WideOrbit installs, we have user buttons programmed to play specific sounders.

Another example would be to really use the ON and OFF buttons on the faders, but use them more like a random button. In other words, we would program those buttons to trip the GPIO PIN because we pushed the button down rather than because the channel turned on.

Fortunately (or unfortunately) there are many answers

Both systems are highly configurable and unfortunately some will see this as a deficiency in one system or the other. But consider this, the exact opposite might also be true. Without the configurability of both of these systems, you would be locked to one way of doing things and our discussion here would be very different. This configurability breeds complexity.

How did we do?