This rough guide looks at the different functions of fixture personality files, trends in complex lighting control interfaces and asks “When is standardisation going to replace fragmentation in the world of stage lighting control?”
Fixture Personality Basics
Intelligent lighting equipment that requires multiple parameters of control has a model specific map of how those functions are controlled. If a fixture requires 30 channels of control, perhaps the first channel is mapped to Intensity with Pan Coarse on channel 3. The other 28 channels all have their own functions including colours, shutters and focus.
The table of channel control functions is not only manufacturer and model specific, but many fixtures also sport a number of control modes that can alter the mapping. Maybe Mode 1 uses channel 4 to control Tilt, while in Mode 3 Tilt appears on channel 3.
The way control channels, commonly DMX addresses, affect the parameters of a specific fixture type is basis of the Fixture Personality.
How do we use Fixture Personality data?
Using a simple DMX preset style desk, knowing the personality of a certain fixture tells us which faders the different attributes. So, we know that fader 1 will control Intensity, for example. But who wants to control complex lighting fixtures using a preset desk? Not me.
Every intelligent lighting control needs personality data to function properly. At it’s simplest, the console needs to know how to assign control channels to the different parts of the desk – Intensity to faders, Pan and Tilt to the position controls etc. When you select Gobo control, it’s no good finding the encoders are adjusting Prism.
So, the console needs to know the personality of the fixture types and these are commonly stored in a library of Fixture Personality files and set during the desk patching process. Currently, fixture personality file formats are proprietary to the specific console manufacturer. This bugs me but more about that later.
Other Fixture Personality File Data Use
So far, we’ve looked at the way a fixture personality file is used to map the different control channels to the interface of the console. This is only a part of it’s use.
Range table data – Some attributes of an intelligent fixture perform different actions depend on their set channel level, for 0 to 255. While parameters such as dimmer, pan and tilt change on a linear scale based on level setting, other parameters such as gobo or colour wheels have set positions that clunk through based on a range of control level. The Open White slot in a colour wheel might be recalled by Colour Wheel 1 > Level between 0 – 17. If your console fiddling experience is to be a positive one, the desk needs to know this.
Control channels can adjust some varied functions depending on range of channel level. Perhaps the macro to Lamp Off the fixture is fired using a Shutter > Level between 220 to 255, you don’t want this happening by accident but you do want to be able to Lamp On using the pre set macro at the console. Range table data within the fixture personality file sorts this out.
Auto Palettes – Patching up a new set of fixtures, you ask the console to generate some standard palettes to get started. White, Red, Amber, Gobo 1, Gobo 2 the list goes on. Using the range table s and other personality file data, the console is able to speed up the building of the blocks by automating some of the process.
The Future of Personality Files
While we are still working with a system that uses a Control Channel / Channel Level and different lighting fixtures exist in the market, fixture personality files will continue to evolve. The latest generation of top end lighting consoles have developed some clever techniques such as integrated colour setting whether CMY, RGB or HSB and Fixture Morphing (attempting to exchange one make of fixture for another with losing your programming). Many of these functions rely heavily on even more advanced fixture personality files and the processing of that data.
This brings me to a personal bug bear of mine.
Anyone who knows me well will know that I have been banging on for years about the benefits of standardising fixture personality files. Here are some of my beefs with the currently proprietary personality formats:
- Not portable between platforms like consoles and visualisers.
- They take console makers valuable time to create. This can makes the personalities released poor quality, with errors and omissions in functionality.
- Fixture makers can change mapping and mode specs. More time spent updating files for every desk maker.
- New fixtures are being added to the market at a furious rate. Every CheepoSpot fixture needs a personality file for the four guys in the world that use the darn things.
The whole thing is so inefficient – why are we creating hundreds of different file types for different consoles and software when the fixture manufacturer could create one – just one personality file. And the correct one. And update it when they changed their firmware. Having proprietary personality files just seems like such a waste of everyone’s time.
Will it ever happen? Will the industry unite around some kind of XML personality file that will fulfil the needs of the simplest control desk and the worlds biggest lighting console?
The lighting business has agreed on DMX512 and the ARTNet protocol is one of a number of widely adopted standards that have been integrated into control equipment. The current mess is the confusion between different media servers and two way communication with different consoles. Getting media thumbnails displayed and other vital tools. But there may be hope on the horizon.
In reality, once one feature has appeared on one console it soon filters down to other makes BUT it is then implemented in each desk makers own “special” way. Let’s face it, the output of a lighting console ends up the same, no matter what gubbins gets between the human and the fixtures. The console makers are only really selling the interface, after all. Surely the differentiation between control only needs to be the interface and the level of functionality
The trouble with an ever more fragmented lighting control market is everyone is so busy trying to differentiate their own product that it sometimes seems like we are getting further from standardisation and away from efficient development.
As each console relies on increasingly advanced personality files, hopes of an integrated standard single file for fixture personality data seems to get further away?
Perhaps the next generation of lighting technologists, the On Stage Lighting readers, will take on the challenge of better standardisation in future lighting control. If you are keen, you might like to take a look at the details of ESTAs ACN (Architecture for Control Networks).
OK, so we’ve taken a quick tour of fixture personality data and you’ve waited patiently while I had a minor rant about standardisation in entertainment technology. Oh, and we have spotted the ACN cavalry far off in the distance. Hopefully, you will have a bit more of an understanding of another vital tool in modern stage lighting – fixture personality data.
With any luck, future development and adoption of ACN will sort out the communication of individual fixture personalities (assume somthing like an XML file), but in the meantime we are stuck with fixture personality files for a while yet.
If you have any thoughts on how the lighting industry should emerge from the sheds and into the 21st century world of development, put your comments in the box below.
Image by Samuel Stroubes