Tag: python

Tally Arbiter 1.2 – support for newtek tricaster, GPO Output, and tsl 3.1 protocol conversion

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.

If you’d like to check out Tally Arbiter or learn more about it, check out the GitHub repository here: https://github.com/josephdadams/TallyArbiter/

Using a Raspberry Pi Zero W and a blink(1) light for silent notifications

At my church, we often delay or “time slip” the preaching of the service in the room where the pastor isn’t physically present. To do this, we record the sermon video as it happens live, and then play it back out either a few seconds or few minutes later.

This has been a good workflow for us. Often though, in the delayed auditorium, it’s helpful for the worship leader to know when the server is ready to play back the delayed sermon video. We usually communicate this over the intercoms into the band in-ears, whenever there’s an appropriate break to do so, like when they aren’t actively singing, praying or talking. That works well, but sometimes it means we have to wait longer than we should to be able to let them know we are ready to play back the video.

So, I thought, if we had a simple cue light that we could use to let them know when we’re ready, I wouldn’t need to have my team wait to communicate. The band could just look at the light and know we are ready for them. It would also give that boost of confidence before they hear from us in the in-ears.

To create this system, I bought a Raspberry Pi Zero W and a blink(1) USB light. If you haven’t heard about the blink(1) light, I wrote about using it in this post. I bought the Pi Zero in a kit that came with a black case and power supply.

91VrInDBG3L._SL1500_
I bought this kit off Amazon for $27.

I had initially envisioned this light being located on stage but after talking to my team, they actually preferred that it be located on top of the camera back in the tech booth, so they could easily see it.

IMG_9294.JPG
Here is the notification light. This is easy to see from the stage. That’s a professional gaff tape install. Currently we move this device back and forth between auditoriums as we alternate which room is the video venue.

I’ve been learning Python recently, so I whipped up a simple Python web server that accepts HTTP requests to then light up the blink(1) light. For now, I’ve limited it to red and green. Red = problem like we aren’t sufficiently delayed, the server is not ready, etc, green = ready/good for playback anytime, and clear/no light = no status. I set up the Pi to start this web server when it boots up, so it’s very easy to set up.

We trigger the light using a Stream Deck Mini running Companion located at the video server. The operator has three buttons, and each one sends an HTTP request to the Pi Zero to trigger the light.

IMG_9295.JPG
This Stream Deck Mini is running Companion and sends HTTP GET Requests to the Pi Zero server.

I also have a command set for each button action on the stream deck to update a button on another stream deck in the other control room, so each director knows the status of the video server. This doesn’t replace our intercom communication, but it certainly augments it!

Overall, we’re very happy with this notification system! All in, it cost us about $55 for the Pi Zero kit and the blink(1) light, and of course, the code was free. 🙂 It’s available on Github if you need it! That’s where I will provide updates as I add more features to this.