I’ve been doing show control since the 1980s, and have watched it evolve along with everything backstage (articles about that here). For the 2026 USITT conference in Long Beach, I was asked to do a session about show control protocols, and so I proposed a live show control demonstration session. This was a great excuse for me to finally learn a little tiny bit of ETC Eos programming and interface with it; this is something I last did in 2014 (that writeup here).

Show Control

I have an entire book on the topic, but basically show control is simply connecting more than one entertainment control system together. There are two basic ways to integrate systems, either in an event-based, “cue” style, or by synchronizing against a show clock using some kind of time code..

The Setup

To get started, this is the setup I built (click any graphic to enlarge) around Figure 53’s QLab on a Mac Mini, and ETC Eos Nomad running on a Windows laptop. I picked these pieces of software because each is widely used.

And here’s the IP addresses and VLAN info:

Impact of the Network on Show Control

Networks have had a dramatic impact on the ease of connecting show control systems together. Ethernet is now the standard digital data highway, and if you’re comfortable with it, a lot of things get a lot simpler. In the old days, connecting systems together was a morass of different electrical interfaces, pin outs, break out boxes, data rates and protocols. We often would advise selection of gear based on which interfaces were available on that gear (see my 1994 book for a time capsule). Except for time code (see below), where there is no widely accepted network-based standard, if you’re comfortable with networks, they are by far the simplest and simultaneously most extensible way to connect systems these days. For the OSC examples I document below, I had each system up and running literally in minutes. In the old days, it would typically take half a day and a lot of rewiring to get things talking the first time (usually due to incomplete documentation)

Let’s go through several ways of connecting the systems, and discuss the relative strengths and weaknesses of each.

Open Sound Control (OSC)

Open Sound Control (OSC) is probably the most widely used event-based show control protocol today, and was developed in the early 2000s as a way to send musical and other control messages. It’s just a framework, and contains no actual control message definitions, so each product developer comes up with their own “dictionary” (here’s the dictionary for QLab; here’s Eos). Developed in the days before the availability of really cheap computer horsepower, OSC requires a low-level formatting and messages have to be “padded” out with if the message is not in a chunk of four octets. I’ve always thought this was a pain in the ass, but, luckily, modern systems do all this grunt work for you. (And in the old days where this wasn’t the case, the developers at Figure 53 helpfully developed a “pseudo-OSC” approach which really simplifies plain text communications when you do have to type something in; more on that here from 2013.)

Here’s a wireshark capture of a message from QLab to Eos firing Cue 1:

So, to fire a cue on Eos, you send from QLab /eos/cue/1/fire 00 , 00 00 00 (where the 00’s are null padding octets—see why I’ve always thought OSC was a pain?)

And to fire a cue on QLab, you can easily configure Eos to send a message automatically. Here’s a wireshark capture:

So that’s /cue/1/start 00 00 00 00 , 00 00 00

OSC from QLab to Eos

Being comfortable with show networks (I have a book on that too of course). with the system plugged up as detailed above, it was trivial to get QLab firing EOS. ETC has a great explainer here.

First, you have to configure Eos to accept OSC messages on the appropriate Ethernet adapter. As you can see in the diagram above, running Nomad on a laptop, I used a second interface for show control to keep the sACN control traffic separate from the show control traffic.

Then, you tell Eos to receive (RX) OSC messages; by default it uses port 8000:

Next, in QLab, make a Network patch with a type of “ETC Eos family”, and enter in the IP address of the Eos interface that you have configured to accept OSC (in my case, it’s 192.168.117.102).

Next, just create a network cue in QLab and just select the patch you made and then just select the Cue (or other action) you want. QLab handles all the low level bits for you—press the send button to test it and that’s it! I literally had this up and running in minutes and it was rock solid.

OSC from Eos to QLab

ETC added a pretty simple feature to fire any QLab cue with the same cue number as it is being executed on the Eos console. ETC has a nice writeup on it here.

In QLab, you need to just make sure OSC is enabled, and set it so that no passcode is needed (passcode reception is on by default which is a good security approach):

Then in Eos, configure the OSC Output, setting the port to 53000 which is what QLab uses for OSC, the send string of “/cue/%1/start” as provided by ETC (there are various options, check the link above), and the target IP address of the QLab system (192.168.117.101 in my case).

For me, again, this worked the first time. However, digging around in Wireshark as I am wont to do, I found that Eos sends quite a bit of status information to QLab to which it then responds with errors. For example, with one Cue trigger from Eos, there was an exchange of over 30 messages:

Being old and coming from the days when processing power was precious, I get paranoid about this kind of stuff. But even though today’s powerful processors and networks can likely handle this with no problem, I’d prefer to clean it up. I asked Figure 53 tech support about this, and they told me there’s a command you can send (via OSC, of course) from QLab to Eos to have it stop the status updates:

/eos/filter/add /cue/*/start

More detail from ETC on this here.

I made a “Custom Message” inside the network cue with the same network patch:

And that cleaned it all up. Here’s the Wireshark capture after a cue message is sent and the filter is applied in Eos:

One important note about this from Figure 53: this filter setting is not persistent and gets reset in the Eos after a reboot. So it’s probably worth adding a cue like this in your preshow test. Hopefully ETC will someday add a system option to disable this.

MIDI Show Control (MSC)

There’s one other common way to trigger systems for event-based show control: using 1990s era MIDI Show Control (MSC). In the 1990s, I was an advocate for MSC, but MIDI is a point to point, old school electrical standard, that was well designed for for its 1980s applications: connecting synthesizers. The seven-bit structure is fine for a keyboard with a maximum of 188 keys, but the low level structure is really not well suited for things like complex show control applications. With networks gaining widespread use in our industry over the 10 or 15 years or so, I prefer to use OSC or other network-based connections methods over anything MIDI (or serial or etc). Once you’re comfortable with networks, it’s a lot easier to monitor and troubleshoot network traffic (MIDIOX, the old shareware MIDI monitoring tool now goes to an unsecure page and was last updated in 2017). It’s a lot easier to send networks long distances, it’s easy to capture traffic with Wireshark, etc etc etc. All that said, there are some times where, for departmental or technological limitation reasons, MSC is the only viable solution. So it’s worth taking a look at it.

I bought a couple little cheap CME C2MIDI Pro USB C MIDI adapters (referral link here) and a couple MIDI couplers so I could plug out to in and in to out (referral link here) (you can see these in the video below). I certainly would not want to hang a professional show on these, and I did have a problem where they stopped working after one of the machines went to sleep. But they are certainly OK for testing and maybe offline programming. I plugged these as shown in the first block diagram. These units are “class compliant” meaning they don’t need additional drivers; they pretty much are plug and play. They just showed up on my Windows laptop and on the Mac Mini:

In QLab, the interface just shows up and you create an output MIDI patch:

To enable MSC In the Eos software you just have to first make sure (on a Nomad setup, anyway) that USB MIDI is enabled:

And then, in the Show Control window, set up to receive MSC. In the old days, MSC might be split or looped thru to several devices (yet another problem we don’t have with network based approaches), so the developers included in the standard a “Device ID”. The idea was if you have two lighting consoles that are being driven from the same hardware MIDI line, you would set each with a unique ID so you could address them separately. These days, MIDI adapters are cheap so personally if I had to use MSC I would drive a separate line to each device, and I just set them all to Receive Device ID 1 as I did here

In QLab, just create a MIDI cue and then select MSC as a message type, then Lighting (general) as a MSC Command Format, the Device ID of 1, and then your cue:

If you put in a Cue Go without a Cue number, it will just execute the next cue.

Time Code

Time Code has its roots in the 1960s as a way to synchronize linear, analog media, and is still used in a wide range of applications today. Two primary solutions evolved over the years, SMPTE LTC (Linear/Longitudinal Time Code), which is digital bi-phase data sent at audio levels, and the 1980s era MIDI Time Code (MTC), which takes the SMPTE time code “address” and breaks it into standard MIDI message. Eos and QLab support both, with appropriate hardware. Note: These days, with networks, it would be great to have a way to send time code over a network, but sadly, there’s currently no standard way to do this; we explored this situation back in our “geekout” in 2019.

LTC

Out of these two options, for me, I would prefer LTC because I can distribute it using standard professional audio equipment or even sample it and distribute it over a network using Dante or something similar. This is kind of insane to me: taking a digital square wave signal, sampling it, and D to A converting it back to an audio signal with a square wave, but that’s where we are today. QLab can generate LTC as an audio signal directly; Eos doesn’t natively deal with audio signals so it needs something like a Response SMPTE Gateway. I didn’t want to invest in this gateway for this test but here’s how I would likely configure it:

Again, being old I like to segment out types of traffic, so I kept the control in the diagram above separate. The SMPTE LTC signal, however, is just audio so can exist on an audio network with no problem. Mark La Pierre has a demo video about configuring LTC on an Eos.

MTC

If I was doing this on a show, I would almost certainly invest in a ETC SMPTE gateway. But for experimenting and programming, MTC can work, I used the MIDI adapters described above. In addition to that configuration from above, for MSC you have to make sure that MTC Receive is enabled in the Show Control menu:

In the Show Control tab on the Eos, make a list, select External to On and the type to MIDI Time Code (in the softkeys):

On the QLab side, create a MIDI output patch:

I put the cues into a group cue in “timeline” mode:

And here’s the time code cue. I started my little show at 01:00:00:00 and have five seconds of “pre-roll” starting at 00:59:55:00. This gives a few seconds before the number starts to make sure everything’s working. For non real time video sync applications, I just use 30FPS non-drop.

When the QLab cue is running, Incoming time code shows up on the top of the Eos screen.

You can enter events manually or use the capture feature:

Here’s a little video:

If you’re going to be at USITT in Long Beach in march, come see this demo’d live!

Special thanks to Nick Gonsman at ETC, John Robinson, my former colleague at CityTech for answering EOS questions, and the great Corn Mo for the use of his .357 Lover track.

Show Control Protocols: Connecting Figure 53 QLab and ETC Eos