There is an amusing scene in Star Wars — Episode II: Attack of the Clones where Obi-Wan is in the Jedi archives looking for information on an elusive planet in some far-off solar system. When he can't find what he's looking for, he asks the librarian. She regrets to inform him, “If it's not in our library, the planet doesn't exist.” Do you ever feel like that when you're on a gig? You open up your spanking new desk to do the patch and realize that the one fixture that makes up a full 30% of your rig is not in the library. Sucks to be you.
Since the dawn of “generic” moving lights, the bane of programmers has been getting good libraries. Never mind the consoles acting up — we've all learned to deal with that — but if the fixture's not there, it's not there. You go home early. Many manufacturers do let you build your own, but opening up the desk and not having them at your fingertips is like pouring a pint of Guinness and not getting any head.
Having worked on both sides of the fence, as both an end user and an R&D guy, I can tell you, the grass isn't greener anywhere. Building fixture libraries has been a great part of my life for the past 10 years — which may explain the gray hair. I was either building my own Hog libraries when the Hog II was not fully released (I was an early beta-tester) or defining the actual library format when developing WYSIWYG. For those who think they've had a rough go of it, let me tell you that building fixtures for control is a much easier task than building them for visualization. If you want a light to do something, more often than not you just tell it where to go and it dutifully follows; there's quite a lot of room for slop. In the other camp, where you are modeling them for visualization, accuracy counts. In the early days, it used to take me about eight hours to fully profile a fixture for WYSIWYG. That included drawing it accurately, both 2D and 3D, figuring out how the manufacturer's specs differed from the real functionality of the fixture's mechanics, timing maximum velocities for all motors and wheels, drawing any special gobos that may get shipped with the lamp, figuring out any wacko macros the fixture may have for playing with the iris or strobe, and generally nailing down every tiny detail of the fixture's four different protocols.
As early as 1995, dealing with everyone's best idea of how to control a light was becoming a real grind. The published AutoFocus protocol specification was intended to simplify the matter so that a generally accepted number of attributes within a simple set of valid parameters acted as a baseline to control any light. Although a number of manufacturers now support Cast's protocol, the original intention has been watered down to setting DMX levels, rather than giving meaningful instructions to the lights and letting the controller figure out what the fixture wants to hear.
Since then, Flying Pig Systems has taken great strides in achieving a more idealistic implementation. The Wholehog III uses what it calls an abstract fixture library. You don't ask a light to pan so many percent to so many percent — which translates to so many DMX to so many DMX. Speaking a little more eloquently, you request a move from so many degrees off axis to so many more. In the early 1990s, Philip Nye was ahead of his time. He wrote a Macintosh-based protocol for DHA Light Curtains using this same methodology. Beyond Light Curtain and Beam Light, the idea never saw much light of day.
So, what's the point of all this? How can this make anybody's life easier? The main goal of describing all fixtures in a consistent manner is twofold. The first is that you can walk up to any light, even one you've never seen before, and you will know what handles to grab to control it. In fact, it will act and respond just like any other fixture you've programmed in the past. No more hunting for silly reset parameters at the end of the strobe attribute (or was it the control channel?). The other bonus from this sort of philosophy is that you can swap out one manufacturer's light for another — even after you've done your programming. Now, depending on how well the library dude did his homework, you may have a show. It's a bit tricky to swap a moving head for a mirror because degrees of pan mean one thing on a head using a polar coordinates system, and quite another thing on a hyperbolic mirror, but you can do it if you're clever. Calibrating color is another fiddly science, as everyone has a different idea of what qualities Medium Bastard Chartreuse should lie heavy in. Calibration is moot too if the lamp itself becomes old and brown.
The whole concept of a control desk manufacturer offering and maintaining a library to ship with its consoles is a thankless task. Users expect it and fixture manufacturers rely on it. I currently maintain the library for Horizon and it is quite a task to collect and process all those DMX protocol spec sheets. Once I build a fixture, I post it on the web and never hear back from the users. Sucks to be me.
At trade shows I often go and meet the engineers that write the code that goes into the microprocessors on the fixtures and ask them what the hell they were thinking. Every one of them has different ideas of where things should go. Some put pan next to tilt. Some don't. Some use sensible barriers within a channel like 16, 64, and 128, where others are fonder of 18, 42, and 91. How does this make any sense?
How many of you have heard of DDL? How about ACN? ESTA's CPWG has a task group working on ACN, and one of its main goals is to define the DDL. (I know: I just broke the “no-more-than-three-acronyms-in-a-sentence” rule.) ACN means Advanced Control Network. No snickering — it's still happening and I'm happy to admit that I was at the CPWG (Control Protocols Working Group) this past January where they actually demonstrated it working. Yes, working. And DDL, or Device Description Language, is the bits of language all devices will carry around that defines who they are, what they do, and how they like to be poked and prodded. Whenever one device meets another, they will shake hands, and then start to scream their respective DDL at each other until one of them listens, wins the argument, and takes charge. This will make our lives easier. We'll just let them all argue about it and when the time comes we'll show them who's boss.
Now, defining a common set of words and structures that will generically describe anything we could possibly invent is a monumental task, especially when the moving light industry has traditionally been steeped in protectionism. There just aren't that many of us around that speak the language. And there are questions to ask: Who is going to be responsible for writing these DDLs? Can we rely on fixture manufacturers to do it properly? Is it too complex for some manufacturers? Will we have a Napster for DDLs where we can all go and trade high-quality ones? What about all the legacy gear in place? How do new ACN controllers see and hear old devices? Will the black box manufacturers build DDL libraries to sit between the old and the new? Will I ever have to write libraries again?
These are tough questions to answer at this relatively early stage of the game. It would be nice if all manufacturers designed their own gear to be ACN-compliant, but my experience is that the documentation coming out of factories never holds up well to scrutiny. May the force be with you.
Find out more about Robert Bell at www.shocklighting.com.