After sitting through several console demos at ETS-LDI 2004, I found myself marveling at just how information-thin most console displays are and how granular the control is. If you think of the live/blind displays we know and love, they really are no different than the displays we had when the consoles operated on DOS.
Information Display theorists such as Tufte (www.edwardtufte.com) have been railing against such thin displays for years now, but our industry has turned a deaf ear. This has been mostly because our consoles are reliant on legacy character-based technologies, and new consoles have inherited the intellectual property (read “development costs”) from their predecessors. This makes sense given the economic realities of developing a new console. But now we can change this as processing power, speed, and graphical operating systems are finding their way into our devices, and we attempt to merge the moving light desk with the conventional light desk.
Studies have also shown that analog displays convey more information faster than digital displays. One need look no further than our cars and airplane cockpits to see this. Digital displays had brief lives in these environments, because we learned that a user could more rapidly gain information from an analog display. A display showing 6.5 gallons of gas is much less useful than a gauge showing we have half a tank.
One big step we need to make is to move away from controlling channels, and then we need to take a step toward controlling lights. Once we make these steps, we can start offering information-rich displays. Of course, we will need to spend more time with the initial setup of a plot. That said, with RDM and ACN promising to allow discovery of the devices on the network, this issue should also diminish. Consoles that integrate with visualization software already have all the information we need to display color, intensity, instrument location, and focus point.
The following display is intended to suggest another way. What you see is two rows of instruments 32 pixels wide x 64 high, plus the instrument number (16 pixels). You will find four samples repeated many times:
- The top number shows instrument number.
- The bottom bar shows gel color at full intensity.
- The main field shows intensity.
- White (or black) squares indicate stage area (area Below: the house, Above: the cyc, Left: SR, Right: SL).
- X indicates focus point.
- + shows instrument location. (X and + could be physically anywhere in the block.)
- The number indicates user selected attribute numeric value.
- Left —, ^, or V shows previous cue's value relative to this cue (same, higher, or lower).
- Right —, ^, or V shows next cue's value.
Such a display could be filtered on any combination of:
- Active (intensity above 0) or inactive
- Static or moving focus
- Current focus
- Static or color changing
- Current color
- Instrument location
This filtering could be additive or subtractive allowing one to easily locate any subset of instruments, and the instruments could be available pre-arranged in groups (essentially submasters on an instrument level).
The numeric value is a user-selectable attribute, not just intensity. Value could be any instrument attribute used in the current plot. The user interface is a radio button interface here.
To edit values, click on the instrument. If multiple instruments are selected, the values are edited as a group (following Windows/Autocad conventions). The editable attributes should dynamically aggregate based on the selected instruments.
This display, while not the definitive answer, shows six times the data in the same area. It answers the question: “Where is that blue light down left coming from?” or “What moving lights are not currently in use?” A further addition would be an indication of the instrument type (short alpha code or the color block shaped like the instrument type) and nature (manual vs. color changer vs. automated) in the static color bar.
With regard to granularity of control, we live in a world in which we are trying to control a fixture or groups of fixtures at the level of each attribute. This is a combination of a logical organization of attributes and an artifact of early DOS and RISC-based computer consoles where data was input numerically.
For instance, in discussing this concept with my colleagues, we found ourselves asking about LED fixtures. Do they have a color value when off or are they colorless when off? When they have a color value is it three values or a single integrated value? I believe the concept of choosing color and intensity as separate values is logical. The user should be allowed to select a color without needing to know its components. This is a concept that the computer should be able to easily facilitate by allowing a user to select a preset color mix or pick a point in a color mix based on a two-, three-, or four-way spectrum of colors representing a full intensity of a mix. This could apply to all additive and subtractive color-changing fixtures. This would not force us to think in terms of component colors as we currently do.
Just as a color is a collection of channels and a fixture is a collection of attributes, a group of fixtures could be set up to function as a unit. This could also apply to other color mixing groups of fixtures such as static-colored downlight washes or three-cell cyc lights. If the console was aware of the gel in each circuit, the console could control each fixture group (cyc up lights as one, cyc downlights as another) as a single fixture, allowing the user to select a color for the cyc and then an intensity.
There is no reason why groups and fixtures need to be addressed exclusively. They could be made available to the user individually and as a group, creating what amounts to submasters on steroids.
Most consoles aim moving lights based on pan-and-tilt console attributes. With consoles holding data on the relative positions of instruments and the focus points on stage, a more intuitive interface is available to us: some current consoles allow us to take a mouse and point an instrument at a target. This is a much more intuitive, goal-based interface. With any instrument attribute we should expect a goal-based interface.
Of course there are many excellent programmers who have the special skills and have developed the knowledge to quickly enter information manually, and this avenue should not be closed to them; it should always be present alongside the goal-based interface.
In summary, it is time for us to be controlling our lighting in a fashion that takes advantage of the processing power available to us today and that takes advantage of the interface standards in acceptance today both inside and outside our industry. A console with a strong information-rich display and a familiar interface is a small step away.
Curtis Kasefang is one of the founding members of Theatre Consultants Collaborative, LLC. He can be reached at [email protected].
ATTENTION
All Designers, Technicians, Manufacturers, Distributors, Groupies, Hangers-On, & Entertainment Technology Geeks:
Got an idea you want to share with your peers? An important industry issue you want to address? Or something you just want to get off your chest? Entertainment Design is always looking for more contributors to its monthly On Lighting, On Audio, and On Projection columns. If you can write and want to share your views with ED readers, please send your ideas to David Johnson at [email protected].