Build your own AMX replacement : part one

The church at which I serve on the production team has an AMX automation system as an integral part of our audio-visual setup. A touchscreen panel allows operators to control the video switchers, cameras, projector screens, the system power, lighting - even, at one point, the locks on the front door!

The user interface of the AMX system, showing controls for one of our three cameras.

On the whole, the AMX has served its purpose pretty well, but there are two big drawbacks to having it:

• It's a hideous big black proprietary box (literally!). Because you need AMX accreditation before they'll give you a compiler, there's no way for us to change how it functions as the needs and equipment of the church change. Ages ago (before I'd joined the church) we replaced our projectors. Because they were a different make, we lost some of the ability to control them via the AMX - we couldn't update the control codes. Unless we shell out for an expensive engineer ordained by AMX, the way things were at installation is the way they'll stay.
• It's now at least ten years old, and old equipment has an inevitable tendency to die when you least want it to. That's not AMX-specific; that's just one of the fundamental truths of A/V engineering. But because it's a proprietary system, and because it's so old, it's extremely difficult and costly to effect repairs. We had a ballpark quote for replacing it with a modern system with similar capabilities: in the region of £12,000.

Twelve.

THOUSAND.

POUNDS.

Even if the church had that sort of money to spare (it doesn't), even I would be hard-pressed to justify spending it on an AMX or similar system when budgets across the board are strained, and for far more worthy causes. Yet with two major failures in the last two years, leaving it be wasn't a good choice either. Surely there must be some other option?

Well, actually, yes (if the title of this blog post hadn't given it away)!

I have a background in software; I work as a technical architect for a software firm, and have always enjoyed the art of programming. Ultimately, I reasoned, what is the AMX? Just a bunch of serial ports and relays, with some software glue between them and a touchscreen controller. And in true Top Gear fashion, I asked myself, "how hard can it be?"

The answer turns out to be "not all that hard, actually". But that's getting ahead of ourselves. I started the project with three clear aims:

• To replicate as fully as possible the functionality and behaviour of the existing system;
• To do so in a way that was easy to maintain and change as the needs and equipment of the church change over time; and
• To do so wherever possible using standard, off-the-shelf components.

Those being defined, I made a few decisions about the direction to start off in:

• Because they're cheap and readily available (not to mention cool), I would base the system around a Raspberry Pi. Note that, since the Pi runs Linux, it could be easily replaced with any other general-purpose Linux computer if needed later. The Pi also has the advantages of being small and low-powered. Most of the other components I needed to source (USB-to-serial adapters, USB relays, miscellaneous other serial gumph) were easily found on eBay or Amazon for a few pounds each. 
• Though I hadn't really used it much before, I decided to write the control and GUI software in Python. It's a ubiquitous language, and in a church the size of ours it's not going to be too hard to find another Python programmer should I ever move on! There are also plenty of libraries available for all sorts of useful functionality: python-serial would take care of the serial port communication, Pyro would deal with the RPC needed between front- and backend systems, and on the recommendation of a colleague, Qt via PySide would be used for the GUI. 
• To keep things simple, I would write both the backend and frontend code in Python; Android and iOS interfaces might well appear in future iterations, but they're not core functionality so they're stuck on the backlog for now. This keeps the first objective - replicating existing functionality - as the priority.

I booked myself a week off work, set up shop in the Parish Centre, and became the church's in-house software engineer. That was back in November, and at the end of the week I had a fairly convincing proof-of-concept working. I'd also drafted, at least in my own mind, a rough deployment plan, dependent on being given a budget for the more expensive components and on being able to find a couple of days to spend installing it.

At least, that was the plan... and then last Sunday happened. And that's where we'll pick the story up next time.