In Praise Of Custom, IP-Based Entertainment Control Part 1

When I started my career, I advocated for universal control solutions, where one control protocol could be used for any type of device, whether it be lighting, sound, video, or anything else. 20 years later, my thinking has shifted 180 degrees. I outline the change in my thinking on page 9 of my book:

The Limitations Of Standards

I have long been (and continue to be) a proponent of open standards. However, I have learned over the years that there are limits to what should be standardized and how much a standard should attempt to do.

In the early 1990s, I was working as a systems engineer for the (now long lost and legendary) lighting company, Production Arts Lighting (PAL). PAL got the job to provide a lighting system for the showroom on a cruise ship, and it was my job to go to Italy and oversee the installation of the system. Looking at the drawings, it became apparent that on the backstage wall of the showroom stage left was to be a mess of different electrical boxes: one sound box full of XLRs and some volume controls; one rigging control box for the connection of a rigging system remote; and a box of ours for house light control, remote focus unit connection, and so on. At that young age, this seemed like a stupid thing to me: Why, when the cruise ship line was spending so much, could they not have a standardized, nicely integrated and well thought out panel-especially one right there on the stage where so many would see it?

Over the years, I've come to realize that not only were a group of individually constructed, wired, and coordinated panels cheaper, but, in fact, better. At PAL, we knew lighting systems, and we wired things a certain way, used certain brands and types of connectors, labelled things in a specific way that made the most sense for the lighting application, and used a specific kind of panel that was made efficiently and in a way we were comfortable working with. Each company on the job had developed a similar method, and had arrived at a very effective way of working, optimized for their process and needs. To force all those vendors to work together on an integrated panel would have cost the client an enormous amount of money in coordination time, and, in the end, would have forced each vendor to compromise in some way, leading to a solution that was mediocre for all and optimized for none.

On the other hand, it wasn't a total free-for-all; some coordination (standardization) was done, where it would benefit the client. For example, to give a consistent look and fit everything into the small control room, the client specified the brand of 19" rack they wanted us to use. This was beneficial to the client, while not being a particular burden to anyone, since all the racks followed the very effective 19" rack standard. (The 19" standard has been very successful because it only defines how panels will mechanically fit, allowing anyone's panel to screw onto anyone's rack. It does not attempt to dictate on what side the power button should be-or if there should be one, what specific indicator lights mean, or how large or small a unit should be.)

Universality of Standards

Drawing the line between what can be effectively standardized and what should be customized is  something I've been fascinated with for many years. For example, I was originally a strong advocate for universal, far-reaching control protocol standards with wide application. With such protocols, a designer would only have to learn and implement one approach and they would be able to communicate with anything. What I didn't realize is that, for a variety of reasons, "universal" far-reaching standards efforts rarely achieve the designers' ambition. Instead, they typically end up either dying off, getting watered down (which may actually make for an improvement), or providing limited functionality to a small subset of the originally intended market. In those situations, it probably would have been more effective to simply address a market subset from the beginning.

For example, MIDI Show Control (see Chapter 26, on page 273) was designed with the ability to control nearly anything in a show. MSC did fill (and continues to fill) some specific cue-based control market niches very well, such as triggering "Go" commands on lighting consoles, or triggering cue-based sound FX playback systems. But MSC never did find universal, all-for-everything application, for both political and technical reasons. Similarly, Medialink, a commercial universal control network, which was covered in the first edition of this book, tried to do everything for everyone. It never was accepted widely enough and crashed and burned badly. The SC-10 working group of the Audio Engineering Society (AES) attempted a wide-reaching standard to provide universal control for any kind of audio equipment (which was covered in the second edition of this book). Unfortunately, many years of work produced only the stillborn AES-24 standard, which was never used by anyone and was eventually retracted by the AES. The list goes on and on.

Why did these fine efforts fail? It's certainly not for technical reasons, since each was developed by smart engineers who were capable of solving all the technical challenges. I would argue instead that they failed for political and commercial reasons, and because they tried to offer too much to too many. For example, while commands like play, pause, and locate make sense for linear video media, they don't make much sense for lighting consoles (as of this writing,anyway), because they typically operate in a cue-based  mode.

Common Attributes of Successful Standards

Does this mean we shouldn't attempt to standardize anything? Of course not, but in my experience, I've found that successful standards have a few things in common:

1. Successful standards are pulled into existence by the market; they are not pushed. They fill a clear commercial demand in the market, especially one driven by users. Often, this means that multiple, noninteroperable systems already exist in a market segment and users are screaming for interoperability.
2. They are limited in scope and ambition and optimized for some task. Consensus standards making processes ensure this, since only a minimal level of functionality will be agreed upon by all the parties involved.
3. They are open for all to use. All of the standards (of which I'm aware) that have caused our market to grow have been open.
4. They leave clear room for expansion and allow shortcomings to be corrected.

I would argue that DMX, MIDI, and (modern full-duplex, switched) Ethernet are successful standards in our market that meet all of these criteria. All three were pulled (not pushed) into existence at the demand of users. They all provide functionality optimized for a particular task; they are all open for anyone to use; and they all left room for expansion. Ethernet is probably the standard that has had the most impact on our market, and it is fast becoming our universal control data transport standard because it does one thing extremely well: transport bits. It doesn't really care what the bits are, and that is its strength. The bits could be lighting data, streaming audio, video files, or porn--Ethernet doesn't care.

I'll talk more about why I'm thinking about this in Part 2.