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



