Full disclosure: I haven’t had a chance to play with Composer yet. This article is based on a demonstration at ISE. I’ll also add that they aren’t the manufacturer that I wrote about on rAVe [PUBS] last week. This article is cross-posted from LinkedIn
The most disruptive feature of Symetrix, Inc. ‘s new Composer software just might be the one that it took several questions for me to get their booth rep at ISE to tell me about.
To add your own control scripts, you use a dialog window to point to a lua script on your PC.
That’s it. That’s the feature.
Why is this so groundbreaking? Symetrix didn’t roll their own version of a lua editor. They let you pick your preferred editor and then they link to it. When you use your editor make changes to your script, they refresh live on the system. You can use all of the native features and plugins associated with your preferred development environment. You don’t have to rely on Symetrix to provide them for you.
Which text editor will you use and why is it going to be Visual Studio Code?
For far too long, we in AV have insisted on adding our own flavor to everything. Just about every control system I’ve worked with has required a convoluted process for using external scripts. Maybe it’s because we all thought we’d be running sound for Beyoncé or playing bass for Neil Young and this is our creative outlet. Maybe it’s because we all drive stick-shift (guilty as charged) and can’t bear to give up that sense of control. Maybe it’s because it’s baked into our industry culture. Whatever the reason, we can’t ever seem to pick a video transport standard or an Integrated Development Environment (IDE) and stick with it.
AV programmers and engineers are the only people I’ve ever heard say “I took the DHCP reservation that they set for me and then I set it as a static IP address.”
I’ve been guilty of this myself. Christopher Tatton once took a look at a file I’d written and noticed that I’d created my own version of several built-in hardware symbols.
Him: “Why didn’t you just tie into the existing architecture?”
Me: “I don’t know, I just like my own version better.”
Him: 🤦🏻
Because I am (occasionally) capable of growth, I used the built-in stuff the next time. And you know what? The sky didn’t fall. The earth didn’t shatter into pieces. In fact, it was easier and faster to program.
Using the built-in stuff is great! Let someone else handle the boring bits. Spend your development time perfecting the UX and making sure that your code is bullet-proof.
Does the built-in stuff sometimes break? For sure. Which is why we need to hold providers accountable for their creations. A task that is made all the easier if they’ve used an IT-industry protocol and not their own version of HDBaseT or Zigbee.
If the IT department messes up our DHCP reservation, we get to insist that they fix it. If the IT department wants to update the IP address range and we’ve set everything as static IPs? Well, now it’s our problem to solve.
A couple stories about DHCP reservations to elevate my point.
- I programmed all of the lighting controls in a large skyscraper. Building integration relied on a complicated system of interconnected controllers. All of the devices talked to each other over the network. The IT department accidentally reassigned the IPs of all of my floor controllers to a bunch of… printers. The worst-case scenario, right? Did I have to give up hours of my precious life to fix this? No. I quoted a five figure sum for fixing their mistake with a reconfiguration. They told me that they’d take care of it on their end.
- I did some work in a large university building. The IT department needed to change the IP scheme of the building (Why? Who knows. Perhaps Mercury was in retrograde). Luckily, this was a relatively flat system, so updating IP addresses didn’t require too many configuration changes. The devices that used DHCP reservations required a simple reboot to update. The devices that one tech decided needed to be set statically? Those required a lot more work and coordination. Most of these rooms required a physical connection to fix. And, because we’d done the misconfiguration, I couldn’t charge the client for this time.
We see this same pattern time and time again with major control systems. They create their own flavor of an existing tool, something breaks, and it takes a major effort to overhaul and update. Sure, you get the occasional security issue where a vulnerability in an underlying dependency is discovered. But you know what’s a lot easier to patch than homemade software? A dependency from a larger organization that has an entire staff of developers working on a fix.
Using modern standards lets us use modern tools. Did somebody else write a cool library with an elegant solution to a requested feature? Import that ish and let them do the heavy lifting for you. If you let your users use any library (and trust them to understand the consequences of this), you won’t have to use crucial developer resources to recreate the wheel.
I recently had to update a file that contained a Simpl# module. It took me a couple of hours to get Visual Studio 2008 (that’s not a typo) onto my laptop, download all of the necessary files, install an ancient .net framework, and fix an imported reference (because Crestron Electronics wrote their own version)
By contrast, if this was a newer system that used C#, it would have been a quick download of a modern IDE and a quick NPM install to get my laptop up and running.
I haven’t had a chance to play with Composer, perhaps Symetrix has committed their own sins. For all of their sandbox missteps, Crestron seems to have learned the error of their way when it comes to C#. Perhaps we’re trending in the right direction.
My hope for this industry is that we can let go of our collective egos and use the tools that other people have created. Ironically, letting go of my ego is what made me a better programmer.
