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:
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 feature has been released, so you can go get it now up on the Github repo!
A couple of weeks ago, I was contacted through the blog by Tony Perez, longtime staff member at Calvary Chapel in Las Vegas. He asked if I could help their team to control their Roland V-60HD switcher through a stream deck using Companion.
God has given me a heart and passion to be a resource for other churches, so I jumped right in and started reading the TCP protocol specification for their video switcher. The protocol was simple enough, basically just a telnet protocol to send parameters with a terminating character to designate the end of the command.
I had to take a sick day recently to take care of one of my kids who had an ear infection, so while he was resting, I sat down and prototyped a module for Companion to control their video switcher.
Tony and I then set a time to talk on the phone and do a TeamViewer session, and after doing some slight debugging, we had it working!
The protocol is pretty straightforward. For example, with this command:
The switcher will perform a cut between the current on-air source and the preview source. “\u0002” is the ASCII control code “02H” which tells the switcher that a command code is coming. “CUT” is the command , and the semicolon terminates the command.
We were able to implement every video-related operation and some of the system operations that seemed necessary to control remotely from a Stream Deck.
So, with just a few short hours of work, now his team can control their Roland V-60HD video switcher from anywhere on their network! This will be a great help and add to their flexibility.
This was a fun project to get to help with, especially since I had not ever seen or used this particular video switcher before, and I was able to help a ministry on the other side of the country.
Here are some pictures of the module in action!
The module is open-source and part of the Companion project now, so anyone else who has this switcher can jump in and use it too! You can view the module code here.
I have always enjoyed finding ways to automate processes, especially ones that don’t require much user interaction but just need to be done at a certain time or at regular intervals. At one of my first jobs out of high school, I wrote software to automate a job for one of the clients that normally took 2.5 days by hand, taking the process down to 30 minutes, including filling out all the paperwork. Of course, the company didn’t like losing those billable hours, but it was hard to argue with the efficiency.
At my church, we have a few computers with limited drive space. And that drive space always fills up fast! In the past, I would check the drives periodically and either delete old files or move them off to another storage place. I sat down recently and decided to take that a step further: I only wanted to be notified to check the drive when the drive was full to a certain threshold.
I’ve been playing around with Slack recently with a project I’m working on at home to notify me when my laundry is finished. If you’ve not heard of Slack, it is a collaboration/communication tool that integrates with lots of other platforms. It’s like a work-specific chatroom on steroids. One of the ways you can use it is with custom apps and webhooks, providing an easy way to send data and interact via a custom URL.
I won’t delve into setting up Slack and webhooks here, but I did want to share with you how I accomplished my goal to only get notifications when the drive is full to a certain amount. I used AppleScript and the Launchd framework built into MacOS.
If you’ve been on the Mac platform for awhile, you’ve no doubt heard of and have maybe used AppleScript. It’s a great way to interact with Mac apps and the system as a whole, so you can automate all kinds of things.
Launchd, as defined by Apple, is “a unified, open-source service management framework for starting, stopping and managing daemons, applications, processes, and scripts.” This framework is always working in the background on MacOS, whether you knew it or not!
So, I sat down and wrote an AppleScript that does the following:
Polls the system for the available space on the hard drive(s) I specified
If the space remaining is a certain amount or less, it sends a webhook request to my Slack app with a custom message to remind me to clear up the particular drive.
Now, to schedule it. In the past, I used to use the built-in iCal/Calendar app for MacOS. It worked ok sometimes but I found that there were times scheduled events simply didn’t run for whatever reason. So, I decided to use a different method and take advantage of the Launchd process built into the operating system. There’s a lot you can learn about Launchd for MacOS, but I’ll summarize it here:
You can run processes as daemons, which run at the system level, not the user level
You can run processes as agents, which run at the user level
You can have them run when the system loads, or you can schedule them
Depending on where you place the file with the instructions about your script determines whether it runs as a daemon or agent
I chose to have mine run on a schedule every day at 7am, and send me an alert if the drive(s) are too full. I didn’t need it to run at the system level, so I made it an agent.
Once I placed this file in my ~/Library/LaunchAgents/ folder (my main user account’s Launch Agents folder) and restarted the computer, it was ready to go! I’m looking forward to not having to remember to check those drive spaces manually anymore. I’ll automatically get notifications on my phone when I need to clear up space!
I hope this helps you! If you want any of the scripts, they’re up on Github.