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.
Have I mentioned before how I love automation? Efficiency at its best.
One of the things I like to automate is the turning on of production equipment on Sunday mornings. It’s nice to walk in for the day and already have equipment turned on and ready to go. It saves me time so I can focus on other things.
In the past, we’ve used crontab on some of the production Macs to send HTTP requests via CURL commands. It worked, but it’s hard to manage when there’s a lot of commands to keep up with. We even tried using GUI interfaces for crontab like Cronnix, but the end result is the same. How do we track and manage all of the commands from a central place?
I came across a tool awhile back called Cronicle. It’s a multi-server task scheduler and runner, with a web based front-end UI. It’s essentially cron but written in Node.js. It can create scheduled and repeating jobs, perfect for ministry activities that tend to repeat.
Cronicle screenshot from their Github repository.
I knew that I wanted to set up a dedicated server to run Cronicle for us. Awhile back, I picked up a used Asus Chromebox CN60 off eBay for $37. I originally bought it hoping to be able to use it with my LiveCaption project, but that didn’t work out. However, the specs on the box are just as good (if not better) than a Raspberry Pi, so I decided to turn it into the server for this project.
Pretty small so it’s not too bad sitting in the rack!
It’s a fairly simple process to remove ChromeOS and install Ubuntu. I won’t detail that here but you can read about it. Installing Cronicle is just as easy if you follow the instructions on the Cronicle Github repo.
Once the server is up and running, it’s time to make some events! I decided to break our scheduled events into some basic categories:
Auditorium 1 (events for equipment primarily in Aud 1 related to regular ministry activities like Sunday mornings)
Auditorium 2
Campus Speakers
Automated Video Recording
General
For example, I have a scheduled event for every Sunday, at 6am, to turn the Auditorium 1 projectors on. It sends an HTTP request using the built-in Cronicle HTTP Request plugin to my Dashboard Production Control system which contains the code to turn the projectors on/off.
Screenshot of an event
I also have the lights turn on using my midi-relay software. It automatically routes the side screens on our Ross Carbonite switchers to the pre-service slides, turns on the campus speakers, etc.
A really nice feature of Cronicle is the ability to add your own plugins. They can be written in virtually any programming language and receive JSON input from Cronicle, so you can customize parameters and commands that get passed to them.
For some of our needs, I’ve created a few plugins so far which I have made available on my Github repository:
Rosstalk – to send commands to Ross Carbonite switchers
VICREO Listener File Opener – to open files, scripts, and programs on remote devices (requires the free VICREO Listener program)
VICREO Listener Hotkey – to send hotkey commands to remote devices
Videohub – to change routes on Blackmagic Videohub routers
I decided to write all of my plugins in Python because the linux server can run them right out of the box with little modifications needed, especially since they are just using simple TCP protocols to send information.
Some of the events I have created so far.
I’m always forgetting to run the video recording, so I automated that. We have a speaker system throughout the campus that has various amps that need to be turned on, so now we can turn them on with a schedule, and even start Spotify playing at a specific time! (This is done by executing an AppleScript on the computer running Spotify.)
We also have an 8-week event coming up in the fall for a Bible study that is at 6am in Auditorium 2. The tech needs are minimal, but they want lights on, a microphone, video recorded, to project some slides, etc. So, we created events to:
Open Vista (VICREO File Opener)
Go to a specific light cue on a specific cue list (midi-relay)
Turn on the projectors (HTTP request)
Turn off the LED wall (HTTP request)
Take the PTZ camera to a specific preset position (HTTP request)
Turn on a mic (midi-relay to a Raspberry Pi connected to the S6L via MIDI)
Route the program audio and video to the Ki Pro recorder (Videohub)
Start the Recording
And then later in the morning at specific times, everything will turn off and go back to normal. We will train someone to be on-site in the event of a change in plan, but this will greatly minimize the need to train someone all of the necessary buttons to press to turn everything on in the right order – it will just happen for them automatically based on the time of day!
Here’s a walkthrough video of it in action:
Overall, I’m very glad to have a centralized system in place to manage these scheduled events to automate our systems and am looking forward to making it even better as we continue to use it. If you want to try Cronicle out for yourself, you can read more about it on their website. It’s a free tool so definitely worth checking out. I have made my simple plugins free as well, and you can get them here: https://github.com/josephdadams/CroniclePlugins
I’ve written a fewdifferent times about Planning Center Online and how we use it at my church. I thought I would share a video walkthrough of how to set up custom checklists for positions as well as our latest custom matrix report.
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.
