A couple of years ago, I wrote about the real-time lyrics sharing software I created to help us be able to send lyrics from ProPresenter straight to people’s phones and tablets at our outdoor worship night. Since then, we have not used this software too much, but I have helped countless other churches get it going for them, especially in this era of doing church differently in a pandemic. Many churches have found this free software valuable so that they could share worship lyrics and other messages while doing outdoor or distanced services.
Now, I have an update!
I have created a client-side app that runs in the system tray to facilitate the connection to ProPresenter and send the lyrics to the cloud server. It also supports several unique “slide notations” that allow you to automate nearly everything just by having a ProPresenter operator click on a slide.
An example of slide notation that PresentationBridge Client supports.
These slide notations are interpreted by the PresentationBridge Client software and are triggered when they are a part of the current slide.
The PresentationBridge Client interface.
The software can also detect instances of ProPresenter (and midi-relay!) running on your network to help make it easier to get connected. It supports sending all of the midi-voice messages that midi-relay supports, as well as a custom shortcode for Chroma-Q Vista, which requires MIDI Show Control in order to remotely execute specific cues on specific cuelists. It can also send out HTTP GET/POST requests, and it can virtually press a Companion button on your remote instance of Companion. This means that you can do just about anything automatically, just by clicking on a slide.
We had a chance to use it in our outdoor worship night back in October, and it worked great! I was making tweaks to it in real-time as people were using it.
We used the new PresentationBridge Client at our outdoor night of worship and it worked very well.
Here’s a video that shows it in action:
This project will be released open-source at some point, but currently I am looking for a few testers to give their feedback. If you’d like to be considered, please reach out to me via the contact form and I will be in touch.
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.
