Fixated on fixture profiles

posted by Jeff | Thursday, January 2, 2025, 11:30 PM | comments: 0

My ADHD has gotten the better of me as I've tried to dive into learning Vectorworks, the CAD program used by pros for lighting design. Sure, there was the chaos of December, but also I tend to push toward practical and applied learning, struggling with the abstract. For that reason, I thought, I want to use my own lights in the software. Unfortunately, the profiles that I have for the lights crashed Vectorworks. I have an open ticket with them, and that sure is disappointing for expensive software.

Still, the nagging problem is that, instead of approaching this systematically a component at a time, I've been looking at the world as a big ecosystem. One of the things that makes all of this stuff interoperable are a couple of standards called GDTF (General Device Type Format) and MVR (My Virtual Rig). The idea is that you can create the profiles, the technical description for how a light fixture works, and use them in all the software. Then you can combine those with stuff like trusses and stages and 3D people, and import the whole lot into grandMA3 or ETC Eos (the two biggest players) and it all just works. This even includes all of the addressing of the fixtures, so there's no manual patching to do when hooking up the real rig. You just have to make sure that the fixtures you hang are set to the ride addresses. For my purposes, it also means imagining a big virtual rig, and being able to control it from the console. In other words, I don't need to actually be at an EDM event to mess with a huge show.

The biggest problem is that my cheap(ish) lights are more targeted for DJ's and small clubs, where they'll probably run off of sound or some other kind of automated thing. What I'm trying to design for is shows running on the fancy consoles. There was a profile for my first two lights that kind of worked from the GDTF share, though it's four years old and kind of janky. The pan ranges were wrong, some of the functions were grouped together in goofy ways, there were quirks. Then the four lights I bought after that were a new iteration, and their pan center changed, along with the order of the colors in the color wheel. So I adapted the janky profile to those.

Tonight I spent a couple of hours refining the profiles, a lot, so they would work as expected. Fixing the pan range (-180 to 360 degrees on the old ones, -270 to 270 on the new) made the most immediate difference, because now what the lights did in the real world matched what they did in the visualizers on screen. I also adjusted the beam tilt -5 degrees, because when they're centered, the beam does not go straight down. Then I reorganized the color wheels and strobe groupings, and finally, I arrived at a profile that worked the same in both MA3 and Eos. And I could import them into Vectorworks and it didn't break!

It could be argued that this was a waste of time, but there were some other benefits. It forced me to better understand the Eos product a bit, which I'm still pretty weak on. This is what's in Simon's school, and even the venues at DPC (which I don't think I could touch anyway, because unions). It also reinforces the way that MA3 "thinks" about manipulating the data that defines state for the lights. This, by extension, makes me think about how I would write my own control software, if for some reason I though that was a good idea. And for the record, I do think I could write something useful, as long as I don't have to get into the geometry of pointing lights at specific points in 3D space. I still find both MA3 and Eos super weird in their UI approaches.

Also, it's cold outside, and the lights warm up my office.


Comments

No comments yet.


Post your comment: