Developing a Switching and Tally Interface for Wirecast and XSplit


While the TriCaster from NewTek has made great strides in decreasing the cost of video switching hardware, and can be credited with some of the rapid expansion of live streaming on the Internet, it still requires an initial investment of about $30,000 on the entry-level. Even though this is down from around 5x or 10x the cost just a few years ago for professional-grade hardware, a significant startup cost is still presented.

This brings us to my day job. For the past 4 years I have worked at PC Perspective, a website dedicated to reviewing PC Components and systems. My job began as an intern helping to develop video content, but quickly expanded from there. Several years ago, we decided to make the jump to live content, and started investing in the required infrastructure. Since we obviously didn’t need to worry about the availability of PC Hardware, we decided to go with the software video switching route, as opposed to hardware like the TriCaster. At the time, we started experimenting with Wirecast, and bought a few Blackmagic Intensity Pro HDMI capture cards for our Canon HV30 cameras (which we were previously recording through Firewire.) Overall, building an 8 core computer (Core i7 980x in those days) with 3 capture cards resulted in an investment of about $2500.


Advantages to the software route not only consisted of a much cheaper initial investment, we had an operation running for about a 1/10th of the cost of a TriCaster (, but it was also more expandable. If we had gone with a TriCaster we would have a fixed number of inputs, but in this configuration we could add more inputs on the fly as long as we had available I/O on our computer.

Fast forward just a few years to today, and the world of streaming has changed even more. New names (and some old ones) have entered the video capture space, including Avermedia, Elgato, and the old faithful Hauppauge. I have done my best to get my hands on this hardware to evaluate, and have been impressed with what these companies have been accomplishing along the way. Personally, I use an Avermedia Live Gamer HD in production for certain scenarios where we have found it has better driver support.

Currently our setup involves a 4 input SDI capture card, the Blackmagic DeckLink Quad, an Avermedia Live Gamer HD, and a DataPath Vision DVI-DL, all in one system, providing us with 6 inputs. We also have a few Thunderbolt Blackmagic Intensity’s which we can add to the machine to give us a few more inputs if needed. We have also upgraded our cameras to Canon HF G20’s and added a few more to the mix.


The software game has changed significantly as well. When we started streaming, just about the only solution for software switching on a computer was Wirecast. We definitely had some growing pains with Wirecast, and were eager to switch to any alternative we could find. This is when we started testing XSplit, over a year ago. While XSplit is built for more of a gaming focus than studio videos like we do, it turned out to be a great alternative and is what we currently use in production. Although I do constantly new software revisions, and Wirecast has gotten a lot better over the years. Other pieces of software I have tried include OBS, and I am currently messing around with FFsplit.


While this software is extremely powerful, and important for lowering the barrier to entry, there are certain things from the broadcast-oriented world that I feel are lacking in the development of this sort of software and hardware. The main thing that I’ve desperately wanted to see is some sort of tally interface for software-based switching setups.


For those of you who may not know what a Tally system does, it is a simple but extremely vital part to any major broadcast. Tally systems consist of lights on top of each camera in a studio, which receive a signal from the video switcher, and light up when that camera is the active shot. While this may seem like an unneeded thing, sitting in front of 3 or 4 cameras becomes very confusing quickly. Being able to quickly glance and see which camera you should be facing and talking to is an invaluable resource.

However, these pieces of software don’t support Tally, and I have never been able to find a piece of hardware that is built around what I wanted. So naturally, I decided to build my own.

For the better part of this year, building a Tally interface for Wirecast and XSplit has been in the back of my mind. However, it’s only recently that I decided to focus on development. The core of this project is everyone’s favorite Microcontroller prototyping platform, Arduino. In particular, one of the catalysts for me actually starting development was discovering the Arduino Leonardo. The Leonardo is special because it features the ATmega32u4, which has native USB communication, as opposed to previous generations which required a separate USB controller. The native controller of the 32u4 allows for emulation of HID devices, which is what piqued my interest.


Wirecast and XSplit both do not have support for tally, and neither program’s API is great, I decided to do something which would make the device appear transparently to whatever video switching software I was using at the time. Since the way that I was physically switching cameras in these programs involved using the keyboard, and assigned macros rather than the mouse, I decided that this would be my way in.

Originally, I ordered a Leonardo and a USB Host shield. My general idea involved plugging a keyboard or dedicated keypad into the Arduino, have it analyze the input, illuminate the correct light, and then use the HID emulation of the Leonardo to pass that back through to the host Operating System. Eventually I stalled on this, and got sidetracked, causing development to stop.


A few weeks later I had a much better idea. Why would I bother intercepting the input of a keyboard? Why shouldn’t the input just be coming from buttons themselves wired up the Arduino? I started development again, and didn’t stop until I reached the working proof of concept I’m showing off today.

To the right you can see a fully assembled prototype which has leads for the tally interfaces, as well as the preview and live switch buttons.



I also recoded a short demo video of this device working in Wirecast, embedded here, and there is a demo video featuring XSplit on the same YouTube Channel.

Now that you have seen my proof of concept Arduino shield, let’s take a look back at the development.


After I came up with the core idea, prototyping went quick. At the end of the first day, I had this device. Nice and simple, I had two momentary buttons, as well as two LEDs connected to the digital pins on the Arduino. If the button on the left was pressed, the Arduino would send a keypress to the host OS it was connected to, and light up the left LED. If the button on the right was pressed, a different key press would be sent, and the other LED would illuminate. Simple as that.


With a working concept, I tackled the next issue, I/O. I knew that I wanted at least 8 buttons and 8 LEDs (ideally 16×16 or more), However the Arduino only has 13 digital IO ports. After doing some research, and comparing the merits of Shift registers and different IO expanders, I settled on the Microchips MCP23017. The MCP23017 is a 16-bit port I/O Expander which communicates over the I2C serial protocol. Using one of these ICs would allow me to expand to 8 inputs, and 8 outputs on the same chip. However, the cool part comes when you daisy chain the chips, allowing expansion up to 128bit (64 in, 64 out in my case).

Arduino provides support for I2c through a library called Wire, which make this process a breeze. The basic idea is to designate the two separate busses of the controller as input or output, and then you can request the current state of each bus. The output is returned as binary, and is positional as to what inputs are high. For example, if the 1st input on one bank of the controller were high, it would return 1. However, if the 4th input were high, it would return 1000. To combat this, I had to create a function which contains a bunch of cases to return a decimal number from this nonstandard binary input.

After the input is sanitized to a decimal number, it is sent to a command which specifies an array. Inside of this array are ASCII keyboard IDs, which correspond to buttons on a standard keyboard. In this case, I am using 225-232, which end up translating to NumPad 1-8. This is mostly just because I used the number pad to switch shots previously, this could be set to any group of keys. The decimal number which is outputted from the conversion function is then used in the array to determine what key to “press” when the emulated HID device sends a signal to the computer. I set up the array to correspond to the button positions, so button number 1 is position 0 of the array, also known as NumPad 1.

In later iterations of the code, I have implemented loading the contents of this “keycode” array from a CSV file stored on a SD card, which is hooked up through the SPI Serial interface to the Arduino. This will allow for user reconfiguration of what keys are being used without having to recompile and upload the microcode to the Arduino, and will be way easier for the end user to tailor it to their own needs.


Here we can see my initial breadboard concept using two of the MCP23017 I2C Port expanders.

Naturally, after I got the code and basic schematic sorted out using a breadboard, I wanted to move onto etching a PCB with my design.

With my only real experience in electronics being a year as a Computer Engineering major before switching majors (to Political Science, don’t ask) the idea of designing a PCB both excited and intimidated me. After opening Eagle and deciding it was way too complex, I ended up settling on designing in Fritzing. While I certainly don’t recommend this due to the lack of portability of the Fritzing file format, and it’s general lack of use in the industry, my resulting circuit board was quite nice. I am currently paying for it now as I attempt to learn to design in Eagle.


Here we have the first revision of this board that I sent off to the OSHPark, who I used as my fabricator. As a side note, OSHPark was great, with about a 2 week turnaround from submission to receipt, a great web interface, and reasonable pricing. Also, there is the added perk that they etch on Purple PCBs exclusively, so the end product looked cool.

If you start to study this PCB, you can see that I made a lot of design errors. First, the most major error is the switching of SDA and SCL channels on the silkscreen. SDA and SCL are the two ports used for communication for the I2C controller, and the integrated part in Fritzing for the Leonardo had these reversed on the silkscreen. Since I did not check this against the actual Arduino, I wired it incorrectly.

Secondly, the buttons are rotated incorrectly on the board for how I have them wired. In this version, I was assuming a horizontal orientation for the buttons in my wiring, but the way the holes are physically drilled meant they could only be placed and soldered in an incorrect configuration.

Beyond that I had some small errors, including the header spacing on the bottom left being incorrect, and the shield not having a cut out for the power plug on the Arduino. I worked around the last one by doubling the headers to connect to the board, making the unit a bit taller, but functional.

This lead me to designing Revision 1.1 while flying on a plane a few weeks ago, and submitting it for fabrication.

shieldrev5.fzz - Fritzing - [PCB View]

I received the board this week, and after soldering the components to the board, I found only one issue this time. The LED headers were connected to a constant 5V power source, and the other pin was connected to the output from the I2C controller. This means that when that output was active, both pins would be getting 5V, which obviously wouldn’t work. While this is actually a major flaw and killed functionality, I managed to cut the trace and run a wire connecting it back to ground, which has worked well so far.

Beyond that issue, this board works great and I am pleased with it. Having a solid prototype is helping me see ideas which I may want to expand on and stress test the overall design some more.

LP6 - group

Looking to the future, I hope to build a unit containing the ATmega32U4 on one board instead of using an Arduino development platform like the Leonardo. I also hope to integrate “broadcast” buttons, which would would find on a much more costly video switcher and contain LEDs under the keycap so you can see the status of the shot without looking at the software.

I am always looking for feedback as to what people might want to see in a device like this, and I know I’m certainly not done working on it. Please leave me any features you think would be cool or what you in general!


About Author

Leave A Reply

Welcome, guest maybe you should register or login