You’re going to work with it a lot, so it’ll help to choose a console that matches your style.
As new digital lighting fixtures and media servers are introduced into our industry, there is a crucial need for an easy way to control what can be a very complicated set of video functions. This is where the lighting console layout can hinder or help the programming process. How a personality for a digital lighting fixture or media server is implemented into a lighting console has a tremendous impact on the performance of the lighting programmer.
Take, for example, the DL.2. Embedded into this fixture is a media server with essentially the same features as the Axon media server. When I program a DL.2, my performance directly depends on the fixture personality in the console I am using. If the personality is too limiting or if it’s laid out in an obscure manner, I will have to spend valuable time searching for the features I need. For this reason, I have been a long-time believer that the feature control channels of a fixture or media server should be labeled the same way on the console that the manufacturer uses in its manuals and DMX protocol. Consoles that break this format and use their own terminology create difficulties that are worth exploring ahead of time if you’re thinking about incorporating this technology into your lighting system.
Channels, Displays and Stress
Why is this idea so important? Imagine that you are the lighting programmer sitting behind a console with a media server or digital lighting fixture connected to the console, and you are about to begin programming with a media server for the first time. How would you get started? The majority of programmers probably start by moving channels until something happens, and through trial and error, they may end up creating something. Then, when they run into something they can’t figure out, they will likely turn to the user manual or DMX protocol charts for more information. If the fixture personality in the console uses broader generic labels, trying to reconcile the console and the user manual will result in a tremendous amount of head scratching while you try to locate a particular function. Many fixtures, like the DL.2, use 16- and 32-bit channels for a variety of features. If those channels are not labeled in such a way that you can easily identify how they correlate to each other, you will have a very difficult time programming until you “learn” which channels affect each other. This is certainly not ideal when the director or LD is breathing down the back of your neck.
Another factor that can impact programming is how DMX values are displayed. A single channel of DMX has 256 different values, with the possibility of a unique feature corresponding to each DMX value. (A great example of this is the Visual FX channel in Catalyst.) If a console displays that particular channel in percentages instead of straight DMX values, you as a programmer will likely have a hard time dialing in the exact value you need without skipping a few settings in between each turn of the wheel. Again, it’s important to look for these settings and make adjustments accordingly where it is possible. (Some consoles have a preference setting that allows the DMX values to be displayed instead of using a percentage.)
Channel Surfing
I also find that it’s much easier if you have access to all of the channels to control a fixture through a channel handle rather than have it buried in a menu. I like having the ability to access the channel directly so I can record palettes (libraries, presets) from the values I need. Some consoles provide quick access toolbars for features — like the color wheel, gobo wheel and strobe — but these toolbars do not provide access to the more detailed settings available for those features (e.g., rotate speed and direction, color modes, rates, etc.). So the toolbars may seem handy, at first, but I find that I tend to abandon using them and go straight to the channels since I usually want to adjust them further.
Menus can present obstacles for a programmer just starting out with a new fixture because they will have to know what feature is in what menu and where to go to find the menu. Anytime a feature is separated from the other channels of a fixture, the programmer will have to search for the button to press that brings up the menu. Likely, too, these menu settings can’t be stored in a palette either, so the programmer always has to use the menu to access the feature. This breaks the flow of routine keystrokes and makes the fixture appear to be much more complex than it really is at times.
Fixture personalities are written by console manufacturers using the DMX protocol provided to them by the fixture manufacturers. If the structure of the software profile doesn’t follow the labeling on the protocol documents, or if it breaks up the fixture into submenus, it can complicate programming, taking valuable extra time while the programmer searches for an effect the LD wants to see. Since the lighting console has a direct impact on the ultimate job performance of a programmer, find the console that fits your approach. No two consoles do things exactly the same way.
Vickie Claiborne is a freelance lighting director, programmer and trainer. She can be reached at vclaiborne@plsn.com.
