Things Every Console Should Have - Part Ten
It’s All About The Data
Rob Halliday
There’s been a lot of discussion over the last decade or
so trying to classify different types of lighting console:
the ‘conventional’ desk vs the ‘moving light’ desk, the
‘rock-and-roll’ desk vs the ‘theatre’ desk. Increasingly, I
think these classifications are wrong - there are plenty of
desks now that deal perfectly well with a mix of moving and
conventional lights, for example.
The one that interests me most is this: desks designed for
one-off shows vs. desks designed to deal with shows that
have a long life, whether that be in a successful run, a
tour, multiple versions around the world, or a rep house
where the show goes away and comes back again years later
(the standard modus operandi for opera and ballet
companies). There are a lot of desks available now that can
handle incredibly complicated shows. There are far, far
fewer that provide the tools users need when dealing with
shows over months, years or decades.
What kind of tools? Well, just think of some obvious
questions you’d love to be able to answer about a show
you’ve just lit: which lights did I actually use (or the
converse, which lights didn’t I use, that we could de-rig
and send back to the rental company?). Which colours did I
actually use in those scrolls - so that for the tour, I can
save money but cutting down the number of frames? Which
gobos did I actually use in the moving lights, so I know
which ones I don’t need to bother loading in the spare
light? Perhaps even more complicated questions: does cue 21
complete before cue 22 runs? When did I last make a change
to cue 10?
Answering any of these questions with any current lighting
console varies from tedious to impossible: there are tricks
for some, others involve scrolling through the show in
blind or recording it running to timecode, others are
probably unanswerable. And those questions are just the tip
of the iceberg.
We tend to think of lighting desks as something special. In
a sense they are, particularly their ability to react
instantaneously, in real time, snapping up the lights on
the beat of the music without the fear of pressing ‘go’ and
seeing a PC-style pause while the machine collects its
thoughts. But step back and look at what they’re doing:
gathering together collections of related information,
providing relationships between those parcels of data (the
channels related to dimmers through the patch, gathered
together into collections called cue states, descriptive
and timing data added to those cues to give cue lists),
presenting the data to the user as requested in a carefully
formatted way. Computer people will recognise that as a
database. A peculiar database, sure - one with timed
transitions between different ‘records’ - but a database
nonetheless.
Except that most consoles don’t treat the data like a
database or, if they do internally, they don’t allow the
user to access that functionality except in carefully
prescribed ways. If they allowed free access, you really
could ask questions like ‘which cues use the colour red?’,
‘which channels never come above 20%’, ‘which cue titles
have the word “Scene” in them?’, or even make changes from
the simple (‘whenever light 1 is on at 50, put it at 60) to
the more complex (‘whenever channel 1 is dark blue at less
than 30%, make it light blue’).
Of course, some consoles already have bits of this
functionality - grandMA has ‘if’, Eos has ‘query’, and I
believe that part of the reason for the longevity of
Strand’s 500-series is the commands it offers for making
mass changes through the entire show, some based on
decisions - ‘if light 1 is at 50, put it at 60 in cues 1
thru 20’. But even that functionality is very limited
compared to what a computer database allows users to do to
its data.
So here’s a question: if your users want to database-type
functionality, why not give them a standard database,
making the ‘console’ a specialist tool for the editing and
playing back of that database?
The sad part is, we were due to have some of this about
now: the successor to the 500-series (the so-called
600-series, which ultimately never appeared after Strand's
takeover by Genlyte, not the current Palette range) was
going to be based on an SQL database - the same kind of
industrial-strength database that powers much of the world
of e-commerce. If you didn’t want to care about this, you
wouldn’t have to - it would just have been a lighting
console. But if you did want to care, all kinds of new
possibilities would open up: learn a little bit about
constructing SQL queries and you’d be able to ask the
console all kinds of questions or make all kinds of
changes. Didn’t want to delve into the crazy world of
computers: fine, let someone else do it and package that as
a ‘find unused colours/gobos’ add-on module; I was betting
that within a year there would be leagues of these modules
available, created by those happy to learn SQL but made
available - for free or for sale - to everyone else.
Plus you’d have been able to access the data over a
network: other programs could have got at that information
in real time. Just as proposed last time, the rig or
paperwork software could have got changes as they were made
in the console - and so always been up to date. Excel can
run SQL queries, so the designer’s cue sheet could have
been updated every time the programmer changed something in
the show.
And it was just a database, so you could extend it if you
wanted to: add a ‘picture’ field to each cue, a date-stamp
field for last time edited, a ‘needs work’ field you could
tag during a run making it easy to find the cues that
needed work the next day ...
To be fair, if you’re doing a one-off show - an industrial,
a tv shoot - you might not care; as soon as the show’s
done, it’s history.
But this is exactly the kind of functionality that the
worlds of plays, musicals, dance and opera are crying out
for: to be able to ask questions of their shows, to be able
to make massive changes to their show quickly and easily to
deal with changes to the show or changed circumstances in
the venue (the opera house that has re-numbered its rig
since show’s last appearance, the ballet company that last
did a show with its touring conventional rig but now has a
rig of moving lights), to be able to get at that
information from places other than when just sitting at the
console - and to be able to adapt their console to deal
with new requirements or new ideas rather than having to
manually sift through data or use other programs to keep
track of it.
Postscript: Turns out there is a console, or at least
console software, on the market that uses an SQL database -
LightFactory from New Zealand. It uses
that information to perform some interesting tricks -
for example, it can calculate the power you’re using at
any given moment, and throttle back the grandmaster if
you’re about to trip a breaker. It’s worth a look...
< Back