About a year ago, I released some camera tally lights software because we desperately needed it at my church. Since that time, a ton of new features have been added, both by me and by the community.
It’s now in use in hundreds of places, from churches to event venues to sports stadiums.
Version 2.0 was silently released a few weeks ago, which includes a compiled application that can run natively on Windows, MacOS, and Linux, without the need to install Node.js and other dependencies like the command line. And, of course, it still runs on a Raspberry Pi.
Lots of people in the community have shared how they are using it, made their own tutorials, and added to the existing documentation.
It’s truly becoming a community project, and I love that. We now have an official Facebook user group to help facilitate conversation amongst users, and I’m excited for the new features on the roadmap in the coming days.
Someone from the community designed a new logo! Isn’t it nice?
It took long enough, but version 1.4 of my Tally Arbiter software is released!
Here are some of the highlights:
First of all, the entire web interface has been rewritten to support the use of the Bootstrap framework. This makes it a lot easier to use, and it looks much better too! Huge shoutout to Matthijs (mg-1999) for taking the time to do this. The bulk of the Bootstrap rewrite is his work.
This is the new interface!
Secondly, Tally Arbiter can now monitor multiple ME’s on ATEM sources, whereas previous versions could only monitor ME 1. This is great if you have more busses that you need to track for on-air sources! If a source goes into preview or program on the ME’s you’ve selected to monitor, and a Device is associated with an address on that source, it will show up.
It’s easy to choose which ME’s will be “on air”.
Third, the Blink(1) and GPO listener clients have been updated to support automatic attempts to reconnect to the Tally Arbiter server, if they start up and the server is offline. This will make it even easier to keep everything connected!
Also, support for Analog Way LiveCore devices has been added, thanks to Alberto (albertorighetto)! So if you have one of those devices, go check it out!
If you use the phone tally viewing page (a very convenient way to turn any phone or tablet into a tally light!), Tally Arbiter has two updates: a QR code has been added to the home page, making it easier for users to navigate to your Tally Arbiter server, especially if you’re running locally and you want to avoid typing in IP address information. Also, your device (if supported) will vibrate or pulse when the selected Device for tally goes into preview or program.
A QR code is automatically generated to facilitate phones and tablets connecting to your Tally Arbiter server.
Lastly, there were a few bug fixes here and there to help with performance.
If you haven’t read about my Tally Arbiter project, you can read about it here and here. Today I’m excited to release version 1.3 which offers some exciting new features!
First, Tally Arbiter Cloud! Now you can send tally data from your local instance of Tally Arbiter to a server in the cloud. Anyone can connect to your cloud server without having to tunnel into your private production network. And, if you are doing remote production with switchers in multiple physical locations or networks, each location can run an instance of Tally Arbiter and the cloud server can aggregate all of the data together in real time! All you need in order to make a connection is a Cloud Key provided by the local client that matches on the server. Keys can be made and revoked at any time.
I’ve set up an Amazon EC2 instance running Ubuntu, with Tally Arbiter running on it. I set a cloud key and set up a cloud destination on my local server to send the data to the server running on EC2. Now, I can log into my EC2 server’s Tally Arbiter web interface and view the tally data from anywhere without having to VPN to the church network. This will make it easy for volunteers to use their personal phones to view tally without having to be in the private network.
Here is a video to show it in action:
Second, Feedbacks and Control through Bitfocus Companion on your stream deck! Companion 2.1 is out now, and if you run the latest build, you can use the new “TechMinistry Tally Arbiter” module to view live tally data from Tally Arbiter on any button on your stream deck. It also supports the ability to “flash” any connected listener client.
Third, a new tally listener client – the M5StickC! This is an inexpensive Arduino ESP32 “finger computer”. A friend of mine in the UK recommended this to me for a possible integration with the project. I bought mine off Amazon for $20 but you can buy them directly from the manufacturer for less than $10. It is a portable, easy-to-use, open source, IoT development board.
Programming this thing was fun because the code is all in C++ which I haven’t used since high school. The power of websockets and the socket.io protocol means that this microcontroller can connect to my Tally Arbiter server and communicate the same way any of the other listening clients do.
Here’s a video to show how it works and how to program one:
Version 1.3 of Tally Arbiter also comes with some other perhaps less exciting but still helpful updates:
All Settings, REST API, and Producer page now require a Basic Auth username/password to access.
In the settings or producer page, if you mouse over the preview and program boxes, Tally Arbiter will show you which sources currently have that device in that bus
The settings page will now show the number of device sources and device actions assigned to a device in the list.
Sources will now attempt to auto-reconnect if the connection is lost with a max retry of 5 times.
Lastly, I’ve set up a website for this project to help others who want to share about it. You can access it at: http://www.tallyarbiter.com
My hope is that this project enables churches and any organization who needs tally for their productions be able to attain it at a lower cost. I’ve put a lot of hours into developing this free software. If it is helpful to you, please let me know!
A few weeks ago, I released some free tally light software to the community. I’ve had people checking it out and I am excited to be able to offer some more features!
Some highlights in the 1.1 release:
Overall performance improvements
Fixed an issue where Devices added during runtime did not obtain a proper initialization state and would not assign tally data properly until the server was restarted
Fixed an issue where Devices mapped to OBS Studio sources could not correctly be in both preview and program bus at the same time (when in Studio mode)
Better checking on Source connection states
TCP/UDP ports are now verified as in-use or reserved to help eliminate user errors
More verbose logging in the server console
All tally data received by all Sources is now sent to the Settings page (while open) for logging and diagnostic purposes
New Producer page; allows users to view all device states (tally information) without having the Settings page open. Created in dark mode for in-service viewing
Documentation added to Settings page to assist in initial setup and learning
OSC added as a Source type to trigger tally states
OSC added as a Device Action type (supports multiple arguments)
“Python” client renamed to “blink(1)” in preparation of other types of listener clients that may also use Python
Version is now displayed on the Settings page for diagnostic purposes
Now, I am releasing version 1.2! The highlights:
Newtek Tricaster support now included as a tally source type
OBS can now properly discern whether it is in preview or program
Support for TSL Clients – Tally Arbiter can now send all device states (derived and arbitrated from any source type) as TSL 3.1 (UDP or TCP) out by specifying a TSL Address for each Tally Arbiter Device. This can be used to drive UMDs and other tally receiving interfaces by acting as a protocol converter between all source types and TSL.
New Python listening client – GPO Output! Now you can trigger just about anything using the GPIO ports on a Raspberry Pi.
Bug fixes and UI improvements
More documentation and upgrade instructions
The biggest feature in this release is the new TSL Clients functionality. Tally Arbiter can now send out TSL 3.1 data to any number of connected devices any time a device changes state within Tally Arbiter. So, you can have, for example, a multiviewer of one switcher dynamically show whether a camera is in use on that switcher or a switcher of an entirely different brand/model by using Tally Arbiter as a protocol converter.
Here’s a video to show how the new TSL Clients feature works within Tally Arbiter and how to integrate it with a switcher like the Ross Carbonite. In this example, tally data is coming from both a Carbonite and a Blackmagic ATEM and the Carbonite multiviewer reflects that in real-time.
Update: Version 1.2 is available now; read about it here:
At my church, we have two auditoriums, each with their own video switcher and cameras. All of the inputs and outputs of each switcher are on a common video router, so all of these sources can easily be shared across both rooms. However, even with all this, we have no camera tally system. Commercial tally systems can be expensive, and it’s just something we’ve never been able to afford.
It’s not normally an issue, but sometimes we want to pull up a shot of a camera in Auditorium 1 and show it in Auditorium 2. Because we have no tally system, the camera operator would not know their shot was being used. And, even if we did have a tally system, those systems generally only interface with one tally source/switcher, not multiple sources at the same time.
A few weeks ago, I was quarantined from work due to a co-worker testing positive for COVID-19. I set out to use this time to write a tally system for our church to use. Now that we’ve re-opened for church services, we will really need this, because we will have cameras capturing the service to stream online, but won’t necessarily have those cameras visible on the projector screens in the auditoriums during that time, where the operators would at least have a visual reference if their shot was in use.
And, because we have two video switchers, I needed to come up with a solution that would allow either video switcher to pull up a camera in either auditorium in Preview or Program, and make sure the operator still knew their shot was in use.
So here is Tally Arbiter. I called it this because the software aggregates tally data from multiple sources and “arbitrates” whether that device is in Preview, Program, or both across all sources and buses.
I played Halo a lot back in the day. A LOT.
The server software is written in Node.js and can run on a Raspberry Pi. It supports the TSL 3.1 network protocol like what our Ross Carbonite switchers use, but I’ve also written support for Blackmagic ATEM switchers, OBS Studio, StudioCoast VMix, and Roland SmartTally. I plan to one day add support for incoming webhooks, and GPIO inputs for switchers that don’t have network-based protocols.
The settings page of the Tally Arbiter server.
The software supports tally data coming from multiple sources, and each source can vary in protocol type. This could be useful, for example, if you had shared cameras for your production on-screen using an ATEM and also through your live stream using OBS or VMix, and you need the cameras to reflect the tally data of either system.
You can configure multiple devices in the software. These would be what generally receives tally data, whether it be cameras, CG stations, monitors, etc. Each device can support addressing from multiple sources. This is the “arbitration” portion of the software.
Once a device is determined to be in preview and/or program, device action(s) can be run. This can be sending out a TSL 3.1 protocol message (to a monitor/scope/multiviewer), an outgoing webhook (to tell another device to start playing a video (“roll clip”), for example), triggering a relay if you have CCUs that need contact closures to turn on the tally lights, or even local console output for logging and testing.
I bought a project box, put the relay in, ran some CAT5e cable I had laying around and connected it to the relay and the CCU’s with custom DB25 connectors. I had to modify the project box some because I wanted the relay to sit flat in the box, so I used a dremel to remove the bottom of the middle screwposts, which weren’t really needed anyway. Never be afraid to modify something to make it work!
The relay fits snugly inside this box. This particular unit has 8 relays, so I could add 2 more cameras with preview/program tally control to this unit.The box and the Pi running the server fit nicely on top of one of the CCUs.A clean rack is a happy rack!Preview and Program lights!This will make our camera operators happy.
But what about the cameras we use that don’t have tally lights? For these, I decided to use Raspberry Pi Zero W‘s that would run software listening over websockets to the Tally Arbiter server. These particular Pi models are inexpensive and simple to use. I knew that I could get the least expensive cost for physical tally lights out of these Pi’s if I went the GPIO route with some LED lights and custom circuitry, but I wanted to design something that people who may not be comfortable with these concepts could easily implement. And honestly, the thought of soldering something just sounded like something I’d have to possibly maintain down the road. So, I used the blink(1) USB lights by ThingM.
I first started experimenting with these USB lights about a year ago when I created a silent notification system for our band to use in case we had a tech issue during a service. The company that makes these has published very easy to use APIs, which makes it a great tool to use with custom software.
I like this simple black case from Vilros. You can get the whole kit minus the SD card for about $30 on Amazon.Here’s a blink(1). A pretty versatile device!
The listener client script is written in Python since that programming language runs so easily on the Raspberry Pi OS no matter what model Pi you have. And, since we are using the socket.io websocket libary, bi-directional real-time communication between the server and clients even though the programming languages vary is not an issue.
I used a USB extension cable to bring the light up by the camera, but the Pi is down on the floor of the platform.Another view.
All together, each wireless tally light should cost between $55 and $60 depending on what Pi case you use, SD cards, etc. Tally Arbiter has no built-in limitation of the number of wireless clients that can be connected, so this makes it a very versatile and flexible system no matter what the size is of your production.
Lastly, I also created an option to view live Tally data in a browser, like on a tablet or phone. You can select the device from the list and the background of the page will be red, green, or black depending on that device’s tally state.
The web based tally option is nice if you need a quick portable tally option.
The web tally is controllable through the Settings page just like any other listening client, so you can reassign the tally remotely and even send a flash to that client to get their attention.
Here’s a walkthrough video of the whole system in action:
As usual with my projects, I’ve made this open-source and available for your use on Github: http://github.com/josephdadams/TallyArbiter. It is fully documented with a REST API if you want to automate use of it outside of the GUI that I have created. There are also step-by-step instructions on how to set up a Raspberry Pi Zero, with OS imaging and all of of the libraries and script installing needed to get it going.
My hope and passion is to see resources like this to be used to further the Gospel. I believe and have seen that God can use technology for His good, and when we can use it to further ministry, that is how we can see the Gospel spread.
If these projects are helpful to you and your church, let me know! I love hearing how you use technology to serve the church.
In my last post, I mentioned my partnership with Tony at Calvary Chapel in Las Vegas, writing software to support their Roland V-60HD switcher.
As I was reading the specs on that switcher, I noticed it had a feature Roland called “Smart Tally”. It allows users to pull up a web page on their phones and monitor sources for being in Preview or Program live as the switcher is used.
I knew I just had to add this support to ProTally, so while working to implement the remote control module, I snooped how the Smart Tally service worked and came up with a way for ProTally to monitor for tally changes the same way mobile users accessing the server directly would.
It was actually pretty straightforward: When a user goes to to the IP address of the Roland V-60HD in a browser, they are presented with a list of addresses. Clicking on any of these addresses then loads a page where the browser repeatedly requests this url in the background:
http://[ipaddress]/tally/[tally address]/status
This status page simply returns three values: unselected, selected (in Preview), and onair (in Program).
Since I wouldn’t have access to the Roland switcher to develop and test with, I needed a solution to be able to test locally. I’ve been learning the Python programming language recently, so I decided to whip up a simple web server in Python to emulate this page request, with it turning one of the three values based on the seconds of the clock. If the time of day was between 0 and 20 seconds, it would return unselected. If between 20 and 40, it would return selected, and finally, if between 40 and 60, it would return onair. This was a simple way to emulate the setup of having a Roland switcher with Smart Tally.
This simple Python script made testing a lot easier!
This feature has been released, so you can go get it now up on the Github repo!
I wrote ProTally last year so our volunteers running ProPresenter could know when their source was on screen or about to be on screen. It has been very helpful in minimizing our mistakes by making distracting graphic changes while on-air. It supports tally data from our Ross Carbonite switchers but I’ve also written support for the TSL 3.1 protocol, Blackmagic ATEM switchers, OBS Studio scenes, and most recently, Bitfocus Companion.
I recently picked up a blink(1) to test out for another project I’m working on. If you’ve not heard of it, the blink(1) is a small $30 USB device with LEDs built in, designed to give you a quick-glance notice of anything on your computer. The creators have made libraries in several popular programming languages, like Node.js (the language ProTally is written in), to interact with it.
I decided to get my feet wet and learn about the device’s capabilities by integrating it with ProTally. Since ProTally can read and work with tally data from so many different types of sources, that means it’s already primed to take that tally data and act on it in different ways, not just on-screen.
So, I am pleased to announce, that ProTally now supports up to 4 blink(1) devices that can mirror the color the user chooses for an on-screen tally box. The user can choose between showing the tally color on a box on their monitor (like normal), a connected blink(1) device, or both. If you are using multiple tally boxes but don’t own an equal number of blink(1) devices, you can also choose to share the blink(1) across multiple tally boxes, and the higher box will get priority.
[wpvideo RL2TDnjS]
The latest release of ProTally supporting blink(1) devices as tally lights is available on Github now, so go check it out!
If you’re using ProTally, I’ve just released a new version that supports custom colors for each tally box, rather than global colors applied to all boxes.
You can download the latest version on Github: https://github.com/josephdadams/ProTally/releases
