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.

Just a quickie: Practice and preparation

I'm feeling a little bit under the weather right now; a sore throat and headache are threatening to break out into full-blown Man Flu, but haven't quite made the decision to yet.

Not enough to stop me from serving at both St Aldates's evening services tonight. The first was covering for someone cut off by the snow, and while running visuals for the service I noticed something odd about myself: quite a few times, and far more than usual, I felt like I needed at least an extra pair of hands. I dropped a couple of cues. I struggled a little to sequence in my head all the components of the service and how I needed to map that to button presses and takes. Not in a big way, and I doubt anyone else would have noticed, but it got me thinking.

When the Late Service I usually serve at takes a break over university holidays, I often find myself with a few weeks off the rota. Inevitably I'll end up covering for someone else in that time, but more than a week or two without being behind the A/V desk and I start to feel a bit rusty, and I'm not as on the ball as I can be. Again, I'm probably the only person who notices, but it always surprises me how quickly I can lose a bit of edge. I suppose that, just like any live performance skills, they do wane without practice.

Tonight, though, I'm not sure that lack of practice was what was affecting me - after a ridiculous run of services over Christmas and New Year, I had a single week off, so theoretically I was both practiced and rested. What I didn't have this week was preparation time.

Usually I put in at least an hour or two of prep for a service. I like to collate all the different orders of service and set lists that various members of leadership pass to me during the week, and create one document I send to the rest of the A/V team. If I'm running visuals I'll start to think about what visual elements might be appropriate, and maybe go looking for new material if my library is lacking. I might think about the lighting in church and how that can complement the other aspects of the service. If I'm running sound then I'll read through the set list with that and the band makeup in mind.

Today, of course, I had time for none of those things. That's okay, and I'm actually quite happy with how the two services ran tonight, all things considered. But it just highlighted to me how important both practice and preparation are to running A/V. Fellow techies, what do you do to ensure you have both?

The third thing I mentioned was, of course, being rested. Yeah, still working on that one... On which note, goodnight ;)