Development Blog #2: Show Control

A core question we needed to answer when designing ShowIO: how do our products talk between themselves and third-party systems, and what language do they use? One of our primary goals as a business is for users to be able to integrate our products with as much of their existing gear as possible - building an open system allows for more customers to use (buy!) ShowIO devices, which allows our business to grow and scale to serve as much of the market as possible. However, the entertainment industry lacks a widely-adopted standard for flexible communication. In industrial automation, Profinet and Ethernet/IP are open standards that connect any I/O device to any PLC; no such standard exists in entertainment technology. So how does ShowIO connect to other show elements?

DMX

DMX is the most commonly used I/O-level communication protocol in live entertainment - almost always in lighting control. DMX and its Ethernet-based children are by far the most successful standards for getting deterministic control data through a lighting rig. DMX is great! It's simple and reliable, everyone understands it, and DMX lighting consoles are super powerful design tools. But for our purposes, DMX has its limits:

• DMX was designed for use with lighting dimmers - you can only send 512 channels (bytes) of DMX data over one universe, and the bytes don't necessarily *mean* anything other than a level 0-255.

• It isn't built for bidirectional communication. RDM is a potential fix for that, but it's locked to a poll-response architecture and its data rates are limited.

• DMX data is repetitive and continuous, which takes up a ton of bandwidth on an already limited RS-485 bus.

• DMX-over-Ethernet solutions can require special network configuration (multicast!) to work properly, and take up a lot of network bandwidth.

• Lighting consoles are great at using DMX data to run a show, but support for DMX communication is worse in PC-based show control software.

Now, for something like a simple power relay, DMX is totally fine - plug it in, set your address, and turn it on and off using one channel. But for a scalable, interconnected system of inputs and outputs, with variable data payloads and communication types, we need something that overcomes these limitations.

Ethernet

We decided out the gate that Ethernet makes the most sense as the medium for our communication to happen. Ethernet is ubiquitous in software, extremely flexible, can carry lots of traffic, and is used widely in entertainment. We also get the bonus of Ethernet being part of a technology stack that includes a ton of useful functionality: data integrity and switching with the Data Link layer, routing and addressing with the IP layer, and ubiquitous connectivity in modern computing via TCP and UDP sockets. Connectors and cable for wired Ethernet are cheap and widely available, cable runs can be long enough for show purposes, and technological infrastructure for Ethernet like switches and routers are mature. Compared to something like RS-485, CAN, or MIDI, Ethernet offers a fast, reliable data link that can be run long distances and installed by any low-voltage electrician worth their salt.

The question of what kind of messages to carry over Ethernet is a much stickier problem. The primary payloads of Ethernet in entertainment fall into a few categories:

• DMX-type data on a lighting network.

• A/V content streaming to audio and video systems.

• Manufacturer-specific links from control surfaces to show equipment.

• Triggering systems for cues on remote devices.

We decided to pull from the last bucket, cue triggering systems, to find ways to communicate with all sorts of third-party systems. Many controllers speak a message format called OSC (Open Sound Control), usually transported using simple fire-and-forget UDP messages, to talk to each other over a show control network. But OSC has a lot of properties that make it usable for ShowIO as well:

Open Sound Control

ShowIO connects to all types of show systems using OSC

• The OSC message format is highly flexible with many data types. We can send bytes, integers, floating-point decimals, strings, and timestamps, to name a few. We can also pack lots of data with different types into one message payload, which is way more efficient than sending many short-payload messages.

• OSC has a human-readable address format that allows us to create a self-describing "tree" of device data and functions. Instead of a smart relay having to know that DMX channel 132 reaching over 50% level means it's supposed to be ON and under 50% it should be OFF, we can program it to listen for an OSC message such as /relay/state with a payload true or false to turn it on and off.

• Sending OSC over UDP is very fast and doesn't require the overhead of an established connection or session. There are no "boot-up" steps that need to happen after lower-layer network connection, making OSC (over UDP) easy to set up and super resilient to power cycles and drops in connection.

• Since OSC is a message format, it's easy to transport over almost any link, not just UDP-over-Ethernet: OSC messages can be exchanged over UDP, TCP, Ethernet, WiFi, Bluetooth, Zigbee, and USB.

• OSC is fast and lightweight to implement on embedded devices, and doesn’t require much additional processing power or memory compared to the base Ethernet stack.

OSC checks both boxes of our boxes: it's widely used in the industry, and is an efficient and flexible way to transport the data we need for our devices. We use OSC to build an API (a list of messages and their associated function) to not only use our I/O data to a show control context, but also to configure and manage our individual devices.

To turn a ShowIO digital output on, it’s as easy as sending an OSC message that looks something like /showio/output/1 True, and when a ShowIO digital input is triggered it can send the OSC message /showio/input/1 True to tell another device its state. Simple, human-readable, and efficient!

We're testing ShowIO's OSC connection with as many different show control systems as we can, and we’re looking forward to sharing some pretty cool examples next week.

If you have any thoughts about ShowIO, or if you're interested in joining our Early Adopter Program to get your hands on beta products, shoot me an email directly at sdick@show-technologies.com.