The evolution of control system programming is interesting to me, from custom languages to a sea of mainstream language support. About 10-15 years ago, I moved from a local AV company supporting churches and community halls to a corporate AV integrator, and what a change it was—first learning about RGBHV and then control systems far different from speakers, multicore, and projectors I was accustomed to. A few years later, I started getting fascinated by control systems and how they worked. At that point, the dominant control system was AMX and their “NetLinx Language.” Fast forward to 2017, and Crestron is now the dominant platform, with their SIMPL join-based programming reigning supreme, with extensions written in SIMPL+ and SIMPL#/Pro, the latter, I believe, based on an early version of C#.

The issue was that you had to learn each programming language and/or style. This is not uncommon in the wider development community though. Starting around 2015, Extron started supporting the Python language in their “Pro” and Ebus systems, and this began the use of mainstream languages. These days, you have a wide range of languages to choose from, with Extron’s Python implementation, Crestron with Native C#, QSC using Lua, and then there is AMX and the MUSE platform that supports Python, JavaScript, and Groovy. But we still have an inconsistent approach. Nevertheless, it is fascinating the evolution each system has taken. The consistency can be found, at least in part, in UI programming, as most, if not all, support HTML5. My guess is due to the ease in displaying the file on a touch panel, being that it only needs a web view or browser window.

So, what are the ups and downs I see here, with no formal training in programming? The adoption of mainstream languages means that as an industry, we can recruit developers from outside the AV industry, and the training required for them to get started is much less, as we are not having them learn new languages. Additionally, we can also adopt some more common development processes. In most cases, we can also use the more “standard” development environments or IDEs.

We can also diversify the existing programming teams. I had mentioned this in another post, but I noticed that the industry standard was that one programmer would work on a control system, regularly working on the main system code or “backend” and the touch panel file or “frontend.” Regularly, the backend, being quite involved, would get much more development time than the frontend. Though with the adoption of mainstream languages, we can now look at having a backend and frontend developer for a project. And yes, this may raise the programming time required, but less so than the older approach.

The downside, then, Ellery, I hear you say. Well, the obvious one, I think, is the cost to upskill existing staff. Often, they have only ever been an “AV Programmer,” meaning they may be less informed on the core principles of mainstream languages. This, with the other somewhat obvious downside of each brand supporting different languages, compounds the issue of upskilling.

The key takeaway here is, in my opinion, that the move to mainstream languages is a good one, bringing in new developers with fresh ideas and expertise. The only issue is, as an AV integrator, what languages and, by extension, systems are you going to support?

Ellery Hulme (they/he)

Ellery Hulme | find the bug, fix the bug, Now we haave 3 bugs, now we have 7 bugs

The Shift to Mainstream Languages in AV Integration