We’re going to keep the train moving in this post, and we’ll talk about taking the console interface software from the last post and connecting it to a message queue and finally to a new interface that will emulate the ‘Montage II’ console using by all variants of the Spyder video processor. By the end of this post, you’ll see a fully working console implementation. Better yet, project partitioning described here can be adapted to easily support different button board hardware, so stay tuned For those impatient like me, I’ve also put the final state demo video right below this sentence (you’re welcome).

First the obligatory high level picture of what we’re going to be walking through (below). On the console we’ve deployed three different applications running effectively as Windows Services. In reality the message queue writer and console emulator apps are running as scheduled tasks which launch on startup, purely due to it being easy to deploy, but they effectively are treated like automatically running services.

1. ScreenMaster to Message Queue Writer: pushes hardware specific messages to a message Queue using standardized JSON messages
2. RabbitMQ: Freeware message queue service maintained by a 3rd party
3. Spyder Console Emulator: Translates messages between a message queue and a Spyder server. A Spyder server will think it’s talking to a ‘Montage II’ controller, which is the official console hardware platform for Spyder.

ScreenMaster to Message Queue Writer

Hardware interfaces come in all kinds of shapes and sizes, and in the case of the ScreenMaster III 3216 there is a hard-coded IP address scheme that makes it hard to develop and debug using a PC other than the built-in one. Other hardware interfaces, like on the ScreenMaster II 1608, use a serial connection inside the console between the hardware and the PC. Due to this, it became obvious early on that normalizing the specific hardware interface using standardized messages on a message queue would be a big help for development and debugging. Another positive outcome is that software can be written for any hardware interface, using any software language, and alas long as it implements the same standard JSON message structures it’ll ‘just work’ with the rest of the application stack.

The code repository for the message queue writer lives in GitHub here. As of this writing, the JSON message formats have not been documented, and so someone interested in making their own interface can look at the full set of classes in the messages folder for the existing project. The general messages from hardware to message queue include Key Action (press/release), Joystick Action, Rotary Action, and T-Bar action. Messages from message queue to hardware include setting lamp(s) on or off, and setting quick key LCDs (color and text). A key being pressed on the console, for instance, would generate a JSON message that looks something like this:

{
  "keyIndex": 102,
  "isPressed": true
}

The other message payloads are similarly simple. I encourage you to take a look at the GitHub project for details. It’s intentionally a small project, and should be easily replicated or adapted to work with other hardware consoles. Here’s a little demo using RabbitMQ’s built-in management interface to get and set messages to the ScreenMaster hardware.

RabbitMQ

I won’t spend a lot of time on this one, since it’s easily Googleable with Bing, but for those of you asking ‘What the hell is a Message Queue and why do I care’? The short version is that message queues allow multiple applications to send and receive messages between each other. There are several different implementations and vendors to chose from, but one (if not the) most popular offering is called RabbitMQ. I’ve installed RabbitMQ on my console, and it runs as a service in the background and launches when the internal computer boots. This works great for the message queue writer and Spyder emulator apps also running on the console, but it’s also REALLY great because I can connect to it from my desktop workstation for development and debugging. Before this I was actually slinging code directly on the console.

But wait a minute, you say, doesn’t putting a message queue between a hardware button board and some software processing create a noticeable degradation in performance? Short answer is no. Slightly longer answer (and in encourage you to look into it more if you’re interested) is that message queues are used as the backbone for enterprises and other environments like stock trading software that demand ultra low latency. There are some configuration options around delivery guarantees that can start to add up in some scenarios, but for our use case we won’t notice any performance impact.

Spyder Console Emulator

With the message queue in place, I have a bridge between a specific hardware interface and a generic messaging system. During that development, it occurred that it might make sense to make another application that would emulate a real Spyder console and translate between the message queue and the Spyder processor. It actually works quite well.

Quick (and relevant) history lesson. The ScreenMaster 3 (and subsequent Montage I console) drew a lot of criticism for having an embedded Windows computer. Other manufacturers (Barco comes to mind) took the opportunity to smear the product as being unreliable because of the internal PC. As a result, the Montage II debuted without any internal PC. The console is VERY simple – it has some simple menu capability to set a local IP and an IP for the upstream Spyder server, and listens for a handful of messages which set button lamps on/off (with an RGB color palette – see picture below) and set LCD text. It will also send network (UDP) messages to the Spyder when a button is pressed/released or if the joystick, rotary, or T-Bar position changes.

If you’re following along in the paragraph above, you may have noticed a couple things. First is that with the console effectively being a ‘dumb terminal’, the Spyder has to manage all of the console state and logic. Second thing is that the messages to and from the console follow a pattern quite similar to what I described earlier with the ScreenMaster to message queue application. Knowing these things, I decided to make one more translator; this time a translator between my message queue and the Spyder console interface.

To make this translation application, I need to do a few things:

1. Determine the button mappings used on Spyder’s Montage II consoles
2. Define a mapping between buttons on the Montage II and my ScreenMaster console
3. Write some software to emulate a Spyder console on the network so the Spyder hardware will actually think it’s talking to a console
4. Make that software in the prior step interact with the message queue and translate messages back and forth.
5. Add a key macro capability to the app which will ‘press’ the correct buttons to configure each of the segments of the console to ensure a desired state for the emulator.

I created yet another Github repository for my ‘Spyder Translator’ with the code and relevant documentation. I created a Visio file with breakdowns of both the M2C-50 (smaller) and the M2C-100 (larger) console button assignments, and I also made a mapping of keys to my ScreenMaster console. Eventually this made it’s way into a JSON configuration file that I put into the repository, but a nice visual representation is always helpful for me. Some pictures from the Visio mapping doc below for reference:

The source code for the Spyder translator project in GitHub isn’t too crazy, and for those interested in looking further it offers a peek at a reference implementation for how the Spyder video processors communicate with networked controllers.

I’ll leave it to the reader to look further at the code repositories and refrain from turning this post into a code dump, but I’d love to hear from anyone who found it interesting or was able to build on it to incorporate some other cool hardware.

So Now Where are We?

At this point the ScreenMaster 3 3216 is an effective tool for controlling a Spyder video processor. The button mapping I’ve created has the quick key buttons mapped as Spyder Function keys, we have source selection and a full transition controller, command key and treatment control. Below is a walk-through video that I put up on YouTube to show off what the console is capable of. I was recording and trying to talk at the same time, so forgive me for the (low) production quality.

Now What’s Next?

The path I’ve gone down so far has been fruitful, but I very much would like to have some better and more native control of Spyder. There are some things I didn’t care for much with the Spyder controller, like only being able to access a single page of command keys or function keys, and not being able to create new items. This is due to the Spyder console never really getting much love – being a play-out device was generally just ‘good enough’.

All that said, I think it would be cool to make a ‘real’ control desk for Spyder, with full control of building things like treatments, command keys, and function keys. Deep integration of the screens to bring better selection context and more rich experiences would really make this thing shine. The timeline will likely come down to how much community interest exists, particularly now with the ability to relatively easily incorporate new and different hardware.

For now, thanks for reading and following along with my project. I hope it is able to tickle a few nostalgia bones out there, as it has for me. Until next time!