Things Every Console Should Have - Part Eight
Freedom To Move Consoles
Rob Halliday

You arrive home from your holiday. You upload the ton of digital pictures you've taken. You want to view them, tidy up the red-eye, make the grey skies look bluer. You want to send the result to your mom. The files are all jpegs, so there are many tools to choose from - the simplicity of iPhoto, the power of Photoshop, or even a combination of many to take advantage of their different strengths. And when you send the end results on you can be sure that everyone can at least view them.

Imagine a world where the only application that could have opened those photo files was the one that came with your camera - one that doesn't have any useful editing tools, and can only save in that same format, so only others with the same application can view the pictures. What a crazy world that would be....

.... except, wait: isn't that exactly the world that all people who use lighting consoles live in? Take your {insert name of any console here} showfile and go to a theatre with a {insert name of any other lighting control here} console. Try to load the show in. You are almost certainly out of luck....

Why is this? Well, on a practical level it's because every console uses a proprietary showfile format, special and unique to it and not publicly documented in any way. The manufacturers will tell you that they have to do this in order to be able to support all of the exciting/new/unique functionality of their console - despite the fact that, ultimately, they're all sending the same numbers out to the same lights. On a practical level it isn't worth trying to reverse-engineer someone else's showfile format - whereas there are plenty of non-Microsoft products that can read Excel files because there's enough demand to make figuring it out worthwhile.

What's really going on is that the manufacturer is trying to tie you in to their console, keeping you using it not because it's the best tool, but because it's the one you used last - traditionally for a show that will have a long life across multiple productions (since multiple productions equals multiple console sales), but now for every show since, increasingly, new shows start from a base showfile of useful bits rather than an empty console. This may be good for them, but is it good for you?'

Take touring. If you're lucky, every theatre you go to will have the same console: the UK tour of Equus in 2008 was that lucky, so we just toured a disk and loaded it in wherever we went, spending the money that would have gone on console rental on lights instead. If you're not lucky? Well, in the old days of conventional lights the low-tech workaround was to manually number-crunch the show in to each new console from a printout. That doesn't work with moving lights. It was tedious even with conventionals, so the far-sighted people at USITT created the 'ASCII Text Representation for Lighting Console Data', a standard defining a human- and machine-readable way of moving lighting data between consoles.

It's worth giving it a read (it's available from the USITT website). It is incredibly detailed. Yet sadly now flawed partly because it doesn't deal with moving lights or any other kind of attributes (scrollers, gobo rotators), partly because the cue and data structures it describes are somewhat limited (no timing-per-parameter, no preset focuses), but mainly - to my mind - because it lets any manufacturer create their own extensions to the standard when exporting data not covered by the standard. The problem then of course being that the standard is no longer a standard, and every console that wants to import ASCII data has to deal with all of these non-standard extensions...... There are lots of consoles offering some level of ASCII export, but their import is usually of the simplest level of information about the show: it works, but not very well for anything other than the most simplistic of productions....

The current version of the ASCII standard is dated March 1992, making it roughly the same age as the DMX standard. DMX, as we all know, has been invaluable in helping the lighting industry grow by letting products from different manufacturers work together. And for the last few years, dedicated teams have been at work on new standards overcoming the limitations of DMX and aiming for the future. As with DMX, the ambition is to give anyone freedom to choose the equipment that best suits their needs rather than being locked into one particular manufacturer....

But if I program my show on console A, I have no real way of moving it to console B. Doesn't that make me rather locked in?

How about a heavyweight team to craft a functional successor to the ASCII lighting console data standard? The aim has to be to create an open data standard for representing a lighting show that any console can write and any console can read: the console becomes just the editing tool rather than also defining how the information gets stored. That way, console choice becomes about picking the best editing tool for any given show at any given moment. I can try the big new thing in lighting control, but switch back to the old one if I prefer it. If I tech a show in a theatre with console A, I can then tour the show to theatres with consoles B, C, D or E - I may not have the same editing tools available, but I can be confident that my show will play back correctly. As a bonus, it keeps manufacturers on their toes, determined to give their products the best tools since any user would be free to move at any time.

Plus it will create a whole new market for tools to manipulate that data. Through the years there have been a host of programs that try to interact with lighting console data, to add functionality that the console people can't or don't want to build in to their own products - think of Eric Cornwell's ground-breaking ExpressTrack, John McKernon's Lightwright, my own FocusTrack. These either choose not to interact with the console at all, die out when the one console they work with becomes obsolete, or take a tremendous amount of work to support what will always be a limited subset of the available consoles. But if there was a standard, it would be worthwhile for software people to develop new tools that manipulated the lighting data in new and powerful and interesting ways.

Achieving this? Hard, of course, as all useful things are. But the payback? I'd argue that it has the potential to be at least as important as the common data interconnection standards since it would provide freedom from the last remaining way that manufacturers can lock you in to their 'system'. Which is, of course, why this would have to be led by an independent trade body rather than any one manufacturer....

< Back