Ever wonder why people avoid pressing that “upgrade firmware” button on their devices? I have a theory …
- Some people suffer from a basic lack of awareness. They don’t know that a better solution is out there.
- Some people are busy. They flat-out avoid updates because it might require them to learn something new.
- Some people are weary of the consequences. It’s just easier to suffer through the quirks and simply turn a blind eye to the promise of improvement.
This scenario is pretty similar to the world of AV programmers. As control programmers, we struggle on a daily basis with outdated process of AV control, dedicated hardware strung together with old tech, and antiquated programming languages. We either accepted these issues as necessary evils, or cling to the ‘if it ain’t broke don’t fix it’ mentality. Or maybe we are simply unware of the alternative.
Enter the new breed of AV customers: IT end users and decision makers. This shift changed the world of AV control overnight. They are demanding control solutions that can easily integrate with standard IT infrastructures, and they want to enable their teams to potentially monitor and service these systems.
All of the sudden, the “firmware update” within our industry which I’m calling “AV Control v2.0” can no longer be ignored. It’s time to hit the “update button” and challenge our existing toolbox, and align our work with more standard IT environments and modern programming methodologies.
Step One – Remove the Complexity
In a typical meeting room, we are programming up to 90 separate control links. When a small change is made to the system – a control ID change, a component added or even a simple gain structure change – there are repercussions that require several back-and-forth conversations between us and the DSP programmer, which can hinder getting a space up and running.
I ran into problems on a recent install that required me to sit down with the DSP programmer to assess the issue. The back-and-forth interplay between us took hours; the process can be maddening!
With a system that combines DSP duties, control processing, conference camera control and routing under one platform, you start to eliminate hardware and more importantly, tons of integration points. There is no back-and-forth because the platform manufacturer has done that work for you!
Suddenly the repercussions of one change aren’t quite as daunting and the complexity of building a system is dramatically reduced.
Step Two – Embrace Open Standards & Modern Languages
Our AV programming tool kit has remained relatively contained within our industry, primarily because the programming languages we use have not evolved at the same pace as the IT world. We have spent a good portion of our careers learning the ins and outs of these arcane languages with only a few outlets for training and sharing.
However, the available tools have evolved. There are better control solutions out there that use standard IT languages and paradigms that are far easier to use and much more accessible outside of this industry.
This is a huge opportunity for us!
Transitioning to more open standards & modern control programming languages will enable AV programmers to work even more efficiently. Our value of that code does not diminished simply because we arrived at the solution with better tools. Quite to the contrary, working in some of these streamlined toolsets are going to open up countless business opportunities that the older architecture simply would not allow. It also frees us up – we can now have more bandwidth and resources to focus on developing solutions that are more advanced.
On top of that, being able to offer a system to the IT customer that empowers them to make those minute-to-minute troubleshooting adjustment will ultimately open more doors. The IT customer is more likely to embrace the solution if they know it is as accessible as the rest of their infrastructure.
Step Three – Allow for Scalability
As companies start to expand their AV capabilities on a global scale, they are looking to invest in technology they can grow at the pace of their business.
Platform-based solutions built around IT standards eliminates the need to “rip and replace” the technology, and allows the end user to scale up or down while maintaining their entire AV programming design and end point configuration.
Furthermore, as these systems scale within the IT infrastructures, the need for system-wide management of AV devices become vitally important. Becoming familiar with software-based management will open doors for additional value added programming opportunities and even additional revenue streams for our companies.
Let’s do this.
This a firmware update that our AV programming community deserves. It’s time to simplify our process and expand our business offering.
5 responses to “AV Control v2.0: The Industry’s Long Overdue Firmware Update”
Hi there. I somewhat agree, but on the other hand: Never change a running system! In my technical life, I had more problems with new firmware, than with less functionality or bugs, not touching my system.
So from my point of view, I will not update any firmware without a massive pressure from a not performing device.
some people avoid to update the firmware because the system is stable and doing what it shall do. Like in the old days with analog gear. The manufacturers only released a product after intense testing. So as client you received what you expected to receive. A stable product out of the box. Something that does not exist anymore apparently… The client has become the Beta Tester because the manufacturer tries to save on development costs. Thats the real reason for firmware updates in my opinion.
I think this is very true and people don’t want to upgrade because of the time it takes to do it…., thank you for your service and info. I’m in.
Bravo. I’ve been saying this for years
If we as an industry can “agree” on a video or audio standard then why is control a by product?
A few manufacturers make it easy and keep the same overall structure across their range for common tasks. But others are still locked into FPGA machine code mentality and this is really unacceptable in this IoT day and age.
I would say the biggest reason I stall on updates is because a lot of times the update comes out and a day later another and then maybe another which means they were using us to beta test the update and in the meantime we look bad in the field when in reality the person or dept that wrote the update didn’t test it in every possible situation, or weren’t given the time to do so