Things Every Console Should Have - Part Four
Making Better Use Of Information The Console Already Has
Rob Halliday
A brief recap, for those who’ve just tuned in (-welcome!
where have you been?): in the second of these articles, I
talked about the concept of ‘building blocks’ of channels -
that when you bring up channels together you are giving a
lighting console extra information, that those channels are
somehow ‘related’ to each other. I suggested that a good
console could let you label those building blocks (‘red
cyc’, ‘stage right crosslight’ or whatever), and then
remember all of that so that when you later came back to
edit a cue, you’d be presented with a handful of building
blocks that you could instantly grab and adjust, rather
than hundreds of channels whose function you had to figure
out before being able to do anything else.
This approach is potentially immensely powerful... but in
many cases we are already giving our lighting consoles a
great deal of this kind of information, particularly when
using colour changers or moving lights. Put a set of colour
changers into ‘red’ and they are working together as a
‘red’ light. Put ten moving lights into ‘down centre’ and
another ten into ‘up centre’ and you’re not really dealing
with twenty lights any more, but with two groups of light -
one down-centre, one up-centre. If you want to adjust the
down-centre pool, why do you first have to remember that
it’s actually channels 1, 3, 11, 17 and 22?
Granted, some consoles let you select these lights easily -
the grandMA’s ‘if’ function, for example, would let you say
‘if downcentre’ to select the lights set to the downcentre
palette, before making further adjustments as required.
That’s all well and good, but you have to know what you’re
trying to find before you can find it, and that just seems
a little crazy....
Whereas if you had the ‘building block’ console from part
two, with its multiple level controllers - wheels, motor
faders or whatever - they suddenly gain a new function. By
default, they’d show you the building blocks that you’d
constructed the cue from. But they could be switched to
show you the ‘dynamic groups’ within the cue - the channels
that you have effectively grouped together by giving them a
common function. Press ‘position’ and the wheels would say
‘down centre’, ‘up centre’, ‘star singer’, ‘piano’, ’drums’
- whatever position palettes are currently live on stage.
Press ‘colour’ and they would say ‘red’, ‘green’, ‘blue’.
Press ‘gobo’ and you’d have direct, immediate control over
the lights making the ‘stars’, ‘dots’ and ‘leaves’ on
stage. As with building blocks, you could then control all
these lights as one, or ‘expand’ that controller out across
all of the available controllers, to be able to balance
lights within the group before then collapsing the group
back down onto a single controller.
Add a couple more control buttons and you’d have even more
versatility, able to select the lights that were both ‘down
centre’ and ‘red’, or perhaps ‘down centre’ or ‘red’. These
are dynamic groups because the groupings - the combinations
- of lights you are controlling form and re-form on the fly
(as you run a cue, or as you change the functions of lights
within a cue), rather than being pre-ordained by creating
‘traditional’ groups. Extend the functionality to intensity
and you’d have a quick way of grabbing all of the lights at
full and turning them down a bit.... And all without having
to do any extra work, over and above that you’ve already
done to set up palettes for positions, colours, gobos and
the like (-and on newer consoles with intelligent libraries
that understand the colour and gobo setups of lights,
there’s an argument for not even setting up palettes for
gobos or colour...)
Better still: extend the functionality to knowledge that
the console has acquired from other places. If it could
read the Lightwright file prepared by the show’s
electrician then, as well as saving you from having to type
the patch in all over again (why can no console do this?),
it could know which lights were on the first electric,
which on boom one right. Now the dynamic groupings could be
by position: ‘#1 electric’, ‘#2 electric’. Sure, turning on
all the lights on the first electric isn’t something you’d
want to do that often - but you do it at least once per
show while making up a rig-check cue. And you don’t have to
use it in isolation - ‘lights on the first electric in
blue’, ‘lights on the first electric that are off’. Add in
colour and purpose information for conventional lights and
suddenly you could bring up the stage right cool shins
without having to use a single channel number, if you chose
to....
Plus, of course, building blocks and dynamic groups
wouldn’t exist in isolation from each other. Sometimes they
might be the same as each other, but sometimes you could
use them to grab intersections (of all the lights on the
band, just select the blue ones - now make them red),
sometimes to grab combinations (while preparing that big
finish: all the lights on the band, and any lights that
aren’t currently on....).
And through all of this process, the multiple level
encoders mean that you’re not just adjusting one set of
levels at a time then having to select the next. You’d have
multiple blocks of light under fingertip control, able to
be mixed as you desire, ‘played with’ until you see
something you like on stage. When it came time to store
that look you could either have a console that had become
better at figuring out what you were actually trying to
record (more on that in later articles...), or the
operation of the console could become a collaboration, the
designer mixing the look and the programmer then taking
that look and dealing with the practicalities of storing
it.
But as a designer, doesn’t mixing a cue like an artist
picking paint from a palette sound like more fun than just
calling out channel numbers and levels....?
< Back