The Future of AV Programming: Part 7

2023 is coming to an end, and I’m so glad. This year has felt like I’ve stumbled out of one bad project right into the next. It’s been a constant battle of double-booking, short timelines, and delayed product. Everyone’s unhappy.

I thought it would be a good time to reflect on the challenges this year, but also to weave in my thoughts on where this is all headed in Part 7 of my Future of AV Programming saga.

I generally frame out a few topics for these posts and try to keep it focused enough that I don’t wander off into rambling. Not this time! This time you get the full stream of consciousness. My thoughts can get pretty jumbled and usually one sparks two more and I never get back to finishing any of them. I’ll try to go back and clean up anything afterward that isn’t made clear but I don’t want to strip the emotion behind the words either.

This year has been a mess. And just to confirm it, I looked at posts from the end of last year. It really has been a constant flood of work. The biggest problem is that for much of 2023, I’ve still been the sole programmer on staff. I’m sure that isn’t all that uncommon in our industry–what with bespoke systems slowly going away. There’s just no need for custom programming on every job. So why do I seem so busy all the time if my pool of work is drying up?

I think one of our recent installs showcases where programmers fill in a lot of gaps. This customer has several rooms with Poly x70 codecs. They’re smaller rooms, but the operation is very straightforward because they’re just running Zoom. The only challenges presented were extender related and networking related. With the extender, the table end receives power from the head end. If the pin-out is wrong, the TC8 receives no power, content can’t be shared, and BYOD won’t work. Pretty obvious signs when something is wrong, and quickly fixed by checking the cable terminations. The networking side requires paying attention to the specifics of the customer network to make sure IP addresses are set correctly, DNS and NTP point to the right servers, and any missing certificates have been installed. All of that, we would consider the “IT world” but programmers have to know basic networking to get devices communicating. So where an “AV installer” may struggle to make sure all the information is entered correctly and consistently, an “AV programmer” is aware that details matter. So while I wasn’t doing any actual programming in these spaces, being a programmer was beneficial because I could fix physical (wiring) and logical (network) problems.

They also have larger rooms with G7500 codecs where we integrated Extron room control on the TC8. It takes a little effort to get the TC8 to connect and pull down the custom UI layout, but programmers are familiar with that struggle already (because our development tools usually aren’t very good). Extron programming is also geared toward non-programmers, so they try to trap you within the confines of configuration. It can be frustrating when you want to do something that would be simple using most programming languages, but configuration locks you into thinking through a problem in a very rigid fashion. Extron does allow running Python programs on their controllers (they call it ControlScript), and I’m signed up for a class at the end of January. Hopefully I can approach systems that way in the future–and blog about it!

I’ve found this year that I’ve spent less and less time in a Crestron development environment. Sometimes I can go a week or two without opening any of their tools. While I did go into 2023 thinking I would build out an HTML5 template powered by C#, there just hasn’t been time. And on top of that, we still have projects that are minor upgrades to existing rooms that re-use non-HTML5 panels (such as TST-902’s). So I still need to bridge the SmartGraphics world while trying to get setup in HTML5. Crestron Construct is now generally available, but my time with it has been minimal–and the experience lackluster. I have hope that it will continue to get better; these things take time. But… I still feel that rolling my own template–that I understand inside and out–would ultimately serve me better. I do worry about putting together HTML5 layouts for new work where I’m not given sufficient time, but that’s where a tool like Construct might really save the day.

Time passes… 

I tried writing this post in one sitting, but I got pulled away. I’m not entirely sure where my thoughts were headed, but I think the gist was I’m making do with the resources I’ve got. I’ll try to pick it back up, but I’m sure you’ll notice a change in tone.

2024 is going to be better. I won’t let project schedules blindside me, which means I’ll be pushing back on timelines more. It shouldn’t be accepted that I’m allowed to deliver unfinished work simply because the schedule was unrealistic. I’ve had to cut features and testing due to not having enough time, and that isn’t fair to the customer, and it isn’t fair to me and what the quality of work reflects.

I’ve written about “correct” programming before, yet I’m still faced with the same challenges on every job: lack of documentation, poor communication. Programmers need to be involved with the project almost from Day 1, not the week before commissioning is scheduled to happen. Catching mistakes in the design (which programmers are good at doing) costs less to fix early in the project than at the very end. And sometimes I’ve had to program around design mistakes when the better solution would have required different equipment.

It seems like this post has turned into more of a future of my AV programming versus the industry’s future, and maybe that’s OK. Maybe that’s what I really need right now: I need a clear understanding of what the standards of AV programming should be. Is it better reusable code? Is it better testing procedures? Is it adopting configuration over programmability?

I think there’s a lot to gain by opening up and sharing our struggles, and stories of what has worked well for others might open up solutions to your own problems. Whenever I feel like I’ve got a rhythm going and work seems easy, that’s when I’ve stumbled into a whole new approach and realize I’ve been missing the whole picture all along. Then I start reading into those methods or technologies, and find myself back at the bottom, again climbing the mountain of knowledge written on that topic.

I want to wrap up with another story about a recent project where we had to pull in another resource, my long-time friend Mark. He’s an excellent programmer and generally Gets Things Done

How can you tell when a job has seriously gone sideways? When there are two programmers on-site! I wanted to make sure I was spreading the work between Mark and I evenly, so I felt like we could tackle the first room together so he’d get up to speed on the program requirements, network layout, and which equipment was installed in each room. The goal was to lose a little momentum on one of the spaces, but then we could leap-frog each other on the remaining ones since they were nearly identical. The challenge with having another programmer touching things is you can’t be certain what state something was left in. Is it running your program? Or theirs? You have to adjust and make sure you’re pulling down the currently loaded version before making any changes, then saving backups just in case. With the two of us working in tandem, we were able to not step on each other’s work and make a push to get all the small rooms finished before I had to fly back home.

Working remotely with Mark still on-site, I had to change to handling just the DSP programming while he worked on the Extron control and physical issues. Just as important that I’m not making unseen changes while he’s in the middle of fixing something, communication between two programmers becomes paramount to making any progress.

There’s no way I could have completed the amount of work without his help, and I think that’s another important lesson: it’s OK to accept help! Sometimes the work load is more than one person can handle, and sometimes an approach is better when you can bounce ideas off someone else. You don’t need to live in a vacuum: open source and collaboration will be huge factors in the future now that these control platforms are less sandboxed and less restricted.

I guess I’ll end it there: I don’t have any major predictions for AV technology going into 2024, but I do hope that my processes become better! And I do hope to start recording some workflow sessions since I think those might have some value looking back on as well.

Thanks for reading! I’ll see you next year!