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.
A few weeks back, I shared about how I am using a Chromebox running Node.js to run an automated scheduling server to control our production equipment. It uses the open-source project, Cronicle, to do this.
Since sharing that post, I’ve created a couple more plugins:
This one is probably obvious, but I’ve made a plugin for Companion. It accepts the IP of the computer running Companion, the TCP listening port (51234), and the page and button you want to press.
The second plugin I’ve made is to control TP-Link HS100 wifi outlets. We have a lot of these around here and we use them to turn on and off equipment remotely. I did some work awhile back to determine the protocol necessary to control them over the network without having to use the TP-Link app. Now we can do this through Cronicle which makes it super easy to automate turning on and off equipment for events.
These are available in the Github repository, so go check them out: http://github.com/josephdadams/cronicleplugins/
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.
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.
If you’ve not heard of Proclaim, it is a presentation software similar in concept to ProPresenter. I’m not a user, but I have had several people write in and ask about how they could control it with a streamdeck, so I though I would share a quick post on how to do this with Companion and the midi-relay software.
This walkthrough will be on the Mac platform.
First, on the Proclaim computer, open the application, “Audio MIDI Setup”.
The Audio MIDI Setup program.
Now, in the Audio MIDI Setup application, go to Window > Show MIDI Studio.
Double click on the IAC driver.
Make sure the checkbox “Device is online”, and click Apply.
Now that the IAC driver is enabled, you need to download midi-relay on the Proclaim computer. You can get it here: https://github.com/josephdadams/midi-relay It is up to you if you want to run it directly from within Node or use a compiled binary. The results are the same.
Once midi-relay is running, you’ll see the terminal output window showing the available MIDI ports.
You can see the IAC Driver Bus 1 listed here.
Now open Companion. It can be running on the same Proclaim computer, or another computer on the same network. In the Web GUI, create a new instance of the midi-relay module.
Search for “midi” in the search bar and the “Tech Ministry MIDI Relay” module should show up.
In the configuration tab, type in the IP address of the computer running midi-relay. If the same computer is running Companion as Proclaim (and midi-relay), you can type in 127.0.0.1.
Now create a new button with a midi-relay action. Choose “IAC Driver Bus 1” for the MIDI Port, and the other MIDI values as you like. Proclaim will detect them in the next step, so the channel, note, and velocity are not too important as long as the note is unique for each action you want to take (previous slide, next slide, etc.)
Now in Proclaim, go to Settings, and click the MIDI Input tab. Click “Add Command”.
Select the command you want to be able to control from Companion. Here, I’ve chosen “Previous Slide”.
There are a lot of options you can control within Proclaim!
Once you select a command, Proclaim will start listening for the MIDI message.
Now go back to the Companion GUI and click “Test Actions” on your button.
Proclaim will detect the MIDI message and apply it to the command.
Repeat this for all the commands you want to control from your streamdeck with Companion and midi-relay.
That’s it! I hope that is helpful! As always, if you need some help along the way, don’t hesitate to reach out to me. If this post or others have helped you, take a minute and learn more about me.
Since the Coronavirus pandemic has shut everything down, like everyone, my whole schedule and routine has changed. Being with my family more is really nice. One significant change is that the church I work at has told everyone to stay home and only be in the office when doing a task that can only be done there.
When that happened, I came up with a workflow that would allow me to run video production equipment housed at the church, from my house, in the event that I couldn’t get to the facility, like a few weeks ago when I had to stay isolated waiting on the results of a COVID-19 test (it was negative).
We have a private VPN connection that I can use at my house with my workstation, which is great because it allows me to access all of the internal network devices at the church while I’m at home. From a networking standpoint, it’s as if I’m there. I can screen share to all my computers and use terminal windows to control nearly everything.
With the private VPN, I have Companion 2.0 running on my laptop with a Streamdeck XL as a control surface. I’m able to control the video router (Blackmagic VideoHub), video switcher (Ross Carbonite), recording equipment (AJA KiPros), and of course OBS. But getting a monitoring feed in real time with audio was a challenge, especially when we have several Netflix, YouTube, and Disney+ streams going!
I made a page that allows me to do basic cuts between the sources on the switcher. I press the button here, the command goes over the VPN to the switcher, and I get visual feedback from the video conference call with Zoom.
I can change scenes in OBS and even have transport control of the AJA Ki Pro, all remotely!
Enter Zoom! And a Blackmagic ATEM Mini! The ATEM Mini is a relatively new device, it’s basically a small portable video switcher. We sort of panic-bought one when this virus was just coming around in our area, in case we needed to be able to do a portable live stream off-campus. Thankfully, we haven’t had to do that yet, but since we have it, I’ve been putting it to use for small events.
The Blackmagic ATEM Mini. It’s a portable 4-input mini switcher.
The ATEM Mini has an HDMI output, but it also has a “webcam output”, which means the sum of your video production can be sent to the computer and received as a normal webcam. This feed can then be brought into Zoom as a camera option!
I am only using one input as this is just a basic HDMI to webcam converter at this point. But if I had more inputs, I could connect them and control it all remotely!
A screenshot of the multiviewer being sent back to me over Zoom.
Overall, I have found it very helpful to have access to this while I work remotely. I could run our live stream on Sundays completely remotely from my house, if I needed to. Along with our Unity Intercom setup, I could even run the switcher and direct cameras from my house for our weekly music recording. I hope I don’t ever have to do that, but it’s nice to know that I could!
Also, since I’m sitting at home more, and being a video DJ for my kids, fulfilling their various TV watching requests, I added a page to the Stream Deck to allow me to control the Roku TV on the other side of the room. This is a module I wrote for Companion that uses Roku’s ECP protocol. It makes life a little easier!
I can control the basic functions of the Roku remote with this module, and even launch Netflix from the push of a button! Now I just need to make it start their favorite shows automatically…
It is amazing what we can do with technology these days, and it delights me to be able to to see technology put to use to serve the church. I hope this is helpful to you! How are you doing remote production during all of this?
