Communities can create incredible things as we’ve seen with open-source initiatives like Linux, but every great community project needs a maintainer to guarantee excellence.
This post is going to look at why I’m opting to forgo community created data in my lighting control system, and instead rely on a commercial offering.
The problem
There exist hundreds of thousands of DMX controllable devices from thousands of manufacturers. Each manufacturer has its standards for defining the DMX control channel specification, with differences ranging from technical like MSB/LSB encoding to inconsistent naming.
It’s this reason that lighting control systems contain a database of controllable devices DMX specifications; to abstract away the differences and make sense of the madness and provide a common denominator.
Historically, controller manufacturers would create their databases, employing one or two people to work full-time on dealing with customer requests. Nowadays, most manufacturers have switched to using 3rd party data providers so they can focus on their core competency of developing control systems.
The Landscape
If you’re looking for DMX data for your own DMX control system, then you have a few options from which to choose. My former employer, Carallon, produces a database used by the industry leaders and is my personal favourite. It has been crafted for more than a decade and includes hundreds of thousands of entries, providing a vast array of information.
Other options include a commercial database called AtlaBase, from the creatures of Capture Sweden, which includes ~16,000 fixture definitions. If you’re looking for free data, then community efforts include an open-source initiative aptly named Open Fixture Library (OFL) which sadly only contains 398 definitions. I should give credit to OFL in that they make use of Github for hosting the personalities and have a continuous integration pipeline to ensure data provided to them conforms to their schema. While the database is small, it is a great start, and I can’t wait to see how it develops.
Enter GDTF
GDTF stands for General Device Type Format and has the ambitious aims of providing a dependable, unifiable and consistent standard for describing DMX fixtures. It includes not just data relevant to lighting control, but also 3D information, including 3D models of each component of the light and how these are connected. The 3D data allows developers to create 3D representations of the lights, and I’m sure it won’t be long until we see an augmented reality app that uses this data.
The GDTF project was conceived and jointly developed by MA Lighting, Robe and Vectorworks, three businesses that have amassed a tremendous amount of respect within the entertainment lighting industry. It’s since been welcome participants from other companies such as Atlabase, Avolites, Carallon, Chamsys, ETC, Martin and Zero88. However, it’s unclear how engaged these companies are with the project, or what their participation has included to date.
Buried within the website is a hidden page for downloading fixture personalities in bulk, which offers the ability to filter the contents. Applying the ‘Uploaded by manufacturer’ filter yields just 37 files all from Robe, which struck me as rather low. A quick look at personalities on the share portal shows user accounts with company names like ACME-Lighting and ARRI-GDTF are uploading personalities, which leads me to think that the companies are struggling to obtain recognition as manufacturers.
Of the participating companies listed on the GDTF site, many have very limited personalities available with the community having created those personalities in many cases. Clay Packy and Martin being two manufacturers where this is very obvious. My impression is that the participants are not actively engaging with the project in any meaningful way and instead, the project is relying almost entirely on community efforts.
Data needs standards
This brings me nicely to my biggest frustration with GDTF and why I’m leaning towards dropping support for it. The community for GDTF haven’t agreed on standard naming conventions, and this makes it difficult to make use of the data in any meaningful way.
Using the download page from before, I applied two filters to ensure the files were at least GDTF version 1.0, and only the latest revision. This resulted in 527 personalities, most of which are almost unusable without significant post-processing.
Inconsistent naming the problem I’ve been grappling with recently as I try to support the format. To best explain why the issues of the naming, let’s start by looking at group names.
I think its safe to assume that the first nine group names would be considered valid but the remaining give names would make no sense in the context of a lighting control system.
Now lets look at the Position feature group. It contains 19 Features for Pan & Tilt, including names such as Pan Motor, Tilt Inifi, Pan Rotate and mspeed.
It’s pretty evident to that mspeed should be a control channel, not belonging under Position group. Pan Motor, Pan Rotate and Pan Inifi represent a Pan feature, but each personality creator deviated from the usual naming conventions.
This deviation can be seen throughout the dataset. Looking at colour, one user has specified slots on a colour wheel as being individual attributes. This innocent mistake by an inexperienced contributor results in the fixture appearing to have nine distinct colour changing mechanisms!
I ran all the personalities through my parser and had it generate a CSV file containing all the group, feature and attribute names and then augmented the data using pivot tables in excel to gain a better understanding of the problem. The images above are the results of different views on the data. It shows just how poor the quality of data provided is.
With visibility to the issues, it became evident that the dataset contained so many inconsistencies and illogical definitions that I shouldn’t invest any further time in trying to sanitise the data. Instead, I’ve opted to halt developing any further support for the General Data Type Format in Light Console. It’s already possible to import GDTF files and control these fixtures if you know the exact attribute name specified within the personality.
Having now spent the time to investigate the ‘open’ alternatives to commercial data, I don’t see much value on the offering, without MA Lighting, Robe and Vectorworks seriously investing in ensuring the data provided are accurate. One of the simplest ways to ensure the quality of data is to put rules in place around naming, perhaps even going so far as to introduce a lookup table of names. Going a step further, they should aim to validate that features genuinely belong to the group to ensure things like mspeed (a control channel) doesn’t incorrectly end up in a position group.
For now, I’ll continue to use the Carallon fixture database service for my fixture data needs as it provides consistent data which adheres to a well-documented set of rules.
Light Console Dev 