Twenty years ago, AV control meant a simple bit of logic and a lot of infrared codes pulled from a giant (and not necessarily trustworthy) database. Today, most devices are network-connected and controlled by an API. In this episode, we’ll explore what this means for the AV programmer, as well as the system designer, and the system owner. Are we as an industry truly realizing the powerful potential that this software-defined revolution offers us? Can the traditional AV programmer keep up, or is this an opportunity to bring a new kind of talent into AV (or both)? We will answer these questions with our guest Lincoln King-Cliby, who has been programming AV systems since the days of IR.

Episode guest

Lincoln King-Cliby
CTS, DMC-E-4K/T/D – Commercial Market Director and Sr. Systems Architect, ControlWorks Consulting, LLC

Lincoln is the Cleveland, Ohio and Washington, DC-based Commercial Market Director and Senior Systems Architect at independent programming powerhouse ControlWorks Consulting. A Diamond Crestron Certified Master Programmer and Extron Authorized Programmer, Lincoln has been involved in professional audiovisual systems design and installation since 1999. Transitioning to full-time AV control systems design and programming in 2005. He particularly enjoys unusual and legislative applications of technology. An avid traveler, Lincoln has visited 22 countries on 5 continents, 39.5 of the United States, and 3 Canadian provinces.

Episode transcript

Justin Kennington (00:10):

Hello and welcome to the season one finale of SDVoE LIVE! I’m your host, Justin Kennington, and this is TV for pro AV. We have a very special guest, an old and personal friend of mine, Lincoln King-Cliby from ControlWorks. He’s a senior programmer there, and we’re going to be talking all about how to control AV today. Twenty years ago, we lived in a world where infrared code databases were what the AV programmer lived and died by. Today it’s APIs and web programming languages and we’re going to break that all down with Lincoln. But first, a couple of programming notes, don’t forget about our aftershow. No matter what happens here on the show today, we will be sitting down after the credits roll with our audience to take questions.

Speaking of season finales, we’ve been at this for seven months now, non-stop every other Tuesday. We’ve come to you with topics from 8K to today’s APIs, HDR to security, lots of interesting stuff.

Justin Kennington (03:18):

What a season it’s been thanks to the production team, producer Paul, producer George and special thanks to Brooke.

Matt Dodd (04:13):

It’s the season finale! It’s emotional, but it’s exciting because we’re getting ourselves ready for next season. We’ll tell you all about that soon, but for now, we’re just going to spend a bit of time talking about APIs, Application Programming Interfaces, with this short clip from our SDVoE academy course, “Unified API = Guaranteed Interoperability”.  Let’s take a look.

We now know that SDVoE is the only truly interoperable standard for matrix switch performance across a 10 gig network. At the heart of this interoperability is the API or Application Programming Interface. This course will give you a deeper insight as to how the API guarantees the interoperability of different endpoints from different manufacturers.

Let’s begin with the acronym. SDVoE stands for Software Defined Video over Ethernet. Video over Ethernet is easy to understand – video distributed over a networking infrastructure or Ethernet – but what does this “software defined” part mean? To explain this, let’s compare a software-defined typology to a matrix-switch typology, or as we like to call it, a “hardware-defined” typology.

In the hardware-defined world, we rely on the matrix switch to manage all the routing configuration and control of the AV signals. In the software-defined world, this is all done with, well, software.

Anyone heading to the sdvoe.org website will see the organization’s mission statement and many keywords will pop out such as “manufacturers”, “designers”, “integrators”, “technology managers”, “Ethernet”, “AV distribution”, “interoperability”, “standardization”, “SDVoE platform”, and “user experiences”. This demonstrates the power of the SDVoE platform.

Matt Dodd (08:52):

Let’s check in with some news articles. First one up is “How to Succeed at AV Programming”. Tell us about it, JK, what did you get from this article? (Visit “Resources” on the episode 16 page in SDVoE Academy for links to the news articles.)

Justin Kennington (09:21):

Steve Greenblatt wrote this piece and he brought up three really important bullets. He talked about the two paths that seemed to exist into AV programming. Some people are AV installers, integrators or designers and ended up taking on a programming role. Others start out as programmers, maybe they have a computer science degree and then they need to learn the AV space. This article is about how both of those people can succeed by being flexible, by making sure code is modular because you can’t afford to write it from scratch for every new job, and by always educating yourself because AV is such a fast-moving target. The programmer rarely gets to choose the AV equipment, and they need to understand how all these different parts and pieces work so that they can create an integrated whole that builds a good user experience.

Matt Dodd (10:11):

It’s a good article. It splits it into three pieces – agility and adaptability; creators of modular, reusable, and scalable solutions; and avid learners committed to the industry.

It uses a phrase that is quite daunting. I don’t know if I like it or not, “If you’re not growing, you’re dying”. It’s probably a bit hard but at the same time, it’s true. Simple systems now don’t really need any programming. People can program it themselves as they use it so these people have to be on the ball. They’ve got to stay with it. They have to be ready to think hard about complex, changeable systems.

The second news piece that you brought up is close to home, the new SDVoE Developer program, which we’ve spent a long time over the last six months developing.

Justin Kennington (11:50):

Tying this all together, those of you who’ve been with us since episode one may remember, we first announced the SDVoE Developer program on that episode. We said it was coming up in the winter and it did, it launched. Be sure to check that out. The program itself is about creating user experiences. That’s something we’re going to dive into with Lincoln, our guest. The idea is to make SDVoE a kind of Android for pro AV – a world where we’re focused on user experience first, the software that creates that next, and then the hardware that’s a critical and crucial component of everything, but it’s not the first decision that you make. We want to see people deciding on a software platform and then SDVoE is that platform for hardware and software. This is much like when you buy a new mobile phone today, what’s the first decision you make? It’s do I want an Android or do I want an iPhone, right? That’s a software platform decision first and foremost.

Justin Kennington (13:19):

Matt, what do you think? You put together training for these people. Give us a short summary.

Matt Dodd (13:24):

This has been great to develop. We spent a long time putting all of this together in a digestible format. There are loads of resource and references throughout the whole program and we did what we do best, which is creating lots of animation to help really explain the whole process and how it is applied. It’s a great course with more to come.

Time to bring on our guest, without further ado, let’s whisk him into shot. Are you there, Lincoln?

Justin Kennington (14:47):

Lincoln, welcome. Good to see you.

Lincoln King-Cliby (14:53):

Thank you. Likewise, it’s been a year.

Justin Kennington (14:58):

I know your background and what you do, but why don’t you tell us a little bit about it and how you got there?

Lincoln King-Cliby (15:06):

I’m a senior systems architect and commercial market director for ControlWorks. We’re an independent programming house, pretty much 100% of what we do is integration programming, AV. I started back in technical theater with a computer science background, so this is where those two crashed together, as it were. I’ve been doing this for longer than I should probably count at this point.

Justin Kennington (15:42):

When we were referencing a news article earlier, we talked about the two main paths into AV programming. One, starting as an AV geek and learning to program and the other, starting as a programmer and learning about AV. You just told me that you took a little bit of both of those paths, but which one would you say you favored personally?

Lincoln King-Cliby (16:04):

I favored the technical theater side because I’m always a tactile person. I love actually seeing things happen, which you don’t get to the same extent with a traditional computer program.

Justin Kennington (16:19):

Do you see any changes in your peers and I guess frankly, in your competitors? I guess my impression is that historically, looking back 10-20 years, every AV programmer was someone who started out as an integrator, designer, a hacker of some kind and learned to program. Is that still mostly true? Do you see more people with formal programming training? Where’s this moving, or is it moving?

Lincoln King-Cliby (16:49):

That’s definitely pivoting. Twenty years ago, the AV programmer was just the smartest installer who got a laptop shoved in their face, “here make this do something useful!”, as a former employer of mine first told me.

As the technologies are getting more complex and more capable, definitely you’re starting to see where those with a more formal computer science or programming education are getting pulled into the industry. There can definitely be advantages and some challenges for both avenues because AV does not work the way a computer program works generally, the way a Windows program works, I should say.

Justin Kennington (17:47):

For sure, that was touched on in Steve’s piece. AV is very different, with different kinds of challenging environments than traditional computer programming, because you have customers changing the requirements as it goes along. You have gear that’s not behaving exactly like it said it was going to behave, and you have to be more flexible than maybe a traditional programmer is expecting. Certainly, that’s interesting. Along those lines of trends and what’s moving where, what do we see in programming languages? Tell us a little bit about how we programmed 20 years ago, and how you are programming today? What’s the structure? What’s the architecture generally look like?

Lincoln King-Cliby (18:27):

Twenty years ago, arguably a lot of platforms you didn’t program, you configured. You took an IR driver and you mapped buttons to features. Then with some of the large manufacturers in the control space, it’s more of a latter logic or event driven, which in plenty of applications I actually still prefer. At least for me, you can kind of trace an action through the steps and get it out the end. Today with everything being cloud-based and internet connected, and a lot of focus on mobile, you’re seeing things like OAuth and RESTful APIs, which would be nice if everyone implemented consistently, but where’s the challenge if everyone actually follows the standard? (Laughter)

Justin Kennington (19:25):

(Laughter) Good question, but I’ll ask the questions here, thank you! On that subject, let’s take that a little further. You talked about AV moving into RESTful APIs and more web-based programming styles. Are we late to that party? Is this the right time for AV? What do you think is going on there? Has the industry been picking those up at the right kind of pace, I guess, is what I’m curious to know?

Lincoln King-Cliby (19:57):

I don’t know that there’s a clear answer for that because I think this is the right time to pick it up. What I’m concerned about is what I’m seeing in some manufacturers, especially on the controlled-device side of things, for example, a thermostat or a garage door, not necessarily traditional AV components. They have an API and they’ll throw it out there, but not document it, not support it, which makes it very hard to integrate when you have a traditional programmer who may work for that manufacturer who doesn’t understand the needs of AV and AV programmers who don’t understand what the traditional programmer was thinking when they defined a term. Struggles ensure.

Justin Kennington (20:54):

I’m curious about the control engines you’re using. Of course, Crestron is going to be a popular choice for the actual control brains and the logic and there’s a few others. I don’t want to leave anybody out, but Extron makes stuff, I think QSC is in that game. My question is not about any one of those in particular, but are those class of devices, those manufacturers’ devices, are they still at the heart of your control systems today? Do you see any movement away, more towards a PC or a Raspberry Pi or some more general piece of compute that’s actually running the program? What do you see there?

Lincoln King-Cliby (21:31):

It’s funny you mention that. When I worked for a university 15-plus years ago, I developed a control system that ran on the PC that was already in every room so that’s definitely an option. Personally, when I’m designing a system, I like to see something from one of those manufacturers that you listed, at the heart of the system, just because it’s a purpose-built piece of hardware that I don’t have to worry about someone trying to install Windows 11 on, or what have you, and then taking the system down in three clicks. But it’s a trade-off.

Justin Kennington (22:15):

(Laughter) Three clicks and reboot, be fair!

Lincoln King-Cliby (22:18):

True, but it is a tradeoff – more hardware, more costs versus games and reliability. So it’s something definitely to consider, but there’s nothing saying that you can’t run it on general purpose hardware if you really, really want to.

Justin Kennington (22:39):

It sounds like there’s no current trend in that direction, right? What’s possible isn’t what’s popular today, still.

Lincoln King-Cliby (22:47):

Not today, not in the vast majority of the customers that I work with. No.

Justin Kennington (22:53):

Something you already touched on a couple of questions ago, but the last thing I want to touch on is what makes an API good and easy to use or bad and hard to use. What’s the difference?

Lincoln King-Cliby (23:06):

In two words, documentation and support. If an API is well-documented and well supported by the manufacturer, generally, it’s going to be pretty. If the API is not well-documented and not at all supported, you wind up pulling more hair out and probably half of my gray hairs are due to poor API designs.

Justin Kennington (23:32):

That makes sense. I won’t make you call out any specific examples of bad, but have you seen anybody that’s done a really great job that’s worth mentioning?

Lincoln King-Cliby (23:48):

I think SDVoE is definitely going down the right track there.

Justin Kennington (23:57):

Thank you.

Lincoln King-Cliby (24:01):

It’s one of the first that comes to mind. Sony APIs aren’t as readable historically, but they’re very consistent so I can take an API for something that’s 20 years old and the current version of the product will likely respond to the same instructions, which is a really nice feature to have.

Justin Kennington (24:23):

It goes back to that modularity so that you don’t have to build something custom and new for every single job.

Lincoln King-Cliby (24:29):

Exactly.

Justin Kennington (24:29):

Let’s put a pause in it right there, please come back and join us for the aftershow. I want to hear about some of the more interesting things you can do now in this new programming API-style world that you couldn’t do before.

Justin Kennington (25:50):

That’s a wrap on season one of SDVoE LIVE!

We’re going to take a summer break and be back in the fall. Spend your summer catching up with our show archive – all 16 episodes!