This is the final entry in my series on the future of AV programming. I started writing it over a year ago, but kept putting it down. It’s probably time to just get something out there and move onto the next idea. Getting my thoughts organized on this topic has been difficult because they keep changing. It’s an underwhelming finish, but the road ahead is widening, making it hard to pin down what’s good or bad about where we’re currently at.
What Customers Want
As far as I can tell, this is what customers want from their technology investment:
Traditionally, programming has implied:
How do we reconcile the traits of custom, programmable systems with what customers are looking to spend money on? We need a way to reduce programmer involvement on each project, and the best way I can see to achieving that goal is having one code base (a framework) that works across multiple systems.
The costs of maintaining one program is significantly less than keeping a separate version for every customer out there. This also allows you to provide routine bug fixes and feature enhancements to customers under a service contract.
Develop one system, but layer options on top of that to give customers the experience they want. Options can be enabled or disabled without the need to involve a programmer, thus saving time and money.
When I started, there were only two dominant control systems: AMX and Crestron. Each one required you to learn their way of doing things. In the end, the results are the same: user pushes button, display turns on, source gets routed, etc.
Crestron is the dominant manufacturer now, and they’ve adopted C# as their platform of choice. Of course, you can still develop using traditional SIMPL and SIMPL+, but to get access to all the capabilities under the hood, you can also throw SIMPL# in there.
Now that Audio, Video, and Control all flow across the same network, the need to have many independent control systems is vanishing. Soon, AV systems will be provisioned by a server running our framework.
Like the idea of “spinning up” a new Virtual Machine instance to meet the increasing demands on a website or service, we’ll be able to “spin up” additional rooms by merely adding control surfaces to them and pointing them back to our server.
AV routing and device control can quickly be added to a room by provisioning it for streaming video. AMX’s SVSi and Crestron’s NVX dominate in this area right now.
Your user experience shouldn’t change a whole lot. The classic example is cell phones. Look at them now: they’re basically all the same because it’s the experience people expect. We’re looking for something similar to happen in AV.
How will we interact with AV equipment five years from now?
I still think the best interaction is the least amount of interaction. If systems can become smarter about the users in them, they can handle a lot of the room setup and tear-down themselves. This will involve tighter integration with the Unified Communications platforms thriving today. It would be great if a user’s preferences followed them around and they could bring that to any space across a company. Someone flying in from New York would have their personal control surface (tablet or phone) interact seamlessly with the equipment in San Diego.
So my advice is:
- Learn web technologies, they’re going to continue shaping our AV world
- Get familiar with using a framework to develop systems (see PepperDash’s Essentials project on GitHub)
- Get comfortable with networking, everything will be connected to a network soon
Thanks for reading!
One thought on “The Future of AV Programming: Part 4”