Awhile back, I wrote about the Shade Controller I created using Node.js and a USB relay running on a Raspberry Pi Zero. It works great. We can raise and lower the shade from anywhere on the network. However, I’ve always wanted a way to control this a little more automatically. The lighting volunteer is typically the person who operates the remote for the shade, so I really wanted a way to automate that part of the process for them so the shade can raise and lower exactly when we want it to, without them having to use an extra tool or device.
As I was working on some networking changes to one of our lighting consoles (we use Jands L5 consoles running Chroma-Q’s Vista 3), I had an idea… What if we could monitor the Streaming ACN lighting network for data changes just like any lighting node, and use that to trigger an action?
If you’ve not heard of Streaming ACN (sometimes called sACN or its official name E 1.31), it is an ethernet based protocol for sending DMX address and value information from a lighting console to receiver nodes which then relay the DMX information to lighting fixtures. It uses multicast traffic to send the information so it is very fast and efficient. At my church, we have several DMX universes of lighting information going over the network for each auditorium, controlling all of the light fixtures.
Luckily for me, a base protocol module for E 1.31 was already available for Node.js. So, using that module, I sat down and prototyped a solution and had something working in just a couple of hours. I’m calling my software sACN Translator. I’ve deployed it to a Raspberry Pi for production. It supports a simple REST API to allow you to control which universes it should listen to, as well as the fixtures to run triggers for. I also created a simple web interface which utilizes this API.
Here is how I set it up on our system to trigger the shade controller. I started by adding two fixtures to the L5 console on Universe 1 (where I happened to have some spare room in my DMX addresses). I called these fixtures “Shades Up” and “Shades Down”, with DMX Addresses 511 and 512.
Then, I added entries in sACN Translator to monitor Universe 1 on the network and look for value changes to fixture addresses 511 and 512. I set it to run an HTTP trigger any time the values reaches 255 (100%). So, when I put the Shades Down fixture at 100% on the lighting console, the software sees that value, looks for a match in its list of fixtures, and then runs the corresponding HTTP request on the Raspberry Pi Zero connected to the USB relay to trigger the action which lowers the shade.
Here is a video of it in action:
Pretty cool! I decided to use separate fixture addresses for each trigger action, but I didn’t have to. I could have just one fixture and watch for two separate lighting values.
So now, all the operator has to do is run the cues like normal, and the programming will do the rest! I’ve made this software available for free on my Github repository. Let me know how it works for you!
A few months back, I shared about the client-side countdown clock script that I created for our team to use. It worked pretty well for its purposes, using Dropbox as the platform to share and update data between the computer creating the clocks and the computer viewing the clocks. The initial goal was to create something that required no backend server and would be easy to run on any computer.
It served us well but we quickly outgrew it with the desire to be able to publish clocks in realtime, not simply relying on the viewer client to refresh itself every 15 seconds to look for new data. So, I created a server based solution using Node.js.
I decided I wanted to run this project on a Raspberry Pi 3 B+, so I picked up this kit on Amazon. I wanted an easy way to spin up a web server that wasn’t tied to any production machine, and this does a great job.
Dubbed TimeKeeper, this project runs an Express web server within Node and has a REST API, which allows the user to poll for existing data as well as create new entries. As new entries are added, they are sent out to all connected clients in real time using the socket.io library.
Rooms allow you to control and specify which timers appear. This is helpful if you are running clocks in multiple venues or instances, and only want certain timers to appear on certain viewer screens.
Timers are the objects that TimeKeeper will count down to, based on the viewer’s current local system time.
Messages can be sent and displayed on viewer clients.
After implementing the API, I created a Dashboard custom panel to interact with the server. This serves as the primary interface for our volunteers. Because the panel fetches new data from the server on a recurring schedule, multiple computers can have the panel open and all stay in sync about what timer and message objects are currently being displayed.
We’ve been using this software for a few months now and it’s working great! I intended to write about it sooner, but with a busy work and family life, finding time to write for this blog can be a challenge!
The next version will support trigger actions when clocks hit a specified time or run out. I also plan to integrate with other clock systems to show time left on video playbacks, Planning Center Online, etc., when I have the time!
Every year, my church has a “night of worship”, a worship service in the heart of the city at an outdoor stage, where we sing songs for a couple of hours. Because it doesn’t get dark enough to use projectors for lyrics until the service is almost over, in the past we have relied on using small flat screen TVs to try to show some words for people to follow along. Big white letters on a black background, nothing fancy. Of course, it’d be great if we could just rent an LED video wall, but the cost to do that has been too expensive for us to do in the past.
So, I had an idea: What if we could somehow send the lyrics out of ProPresenter to everyone’s phones, in real time, and let them use their own screens to follow along?
I gave myself a couple of limitations:
It needed to work in the standard phone browser so there was no barrier of installing a particular app
It needed to be real time or as close to it as possible
Awhile back, I started tinkering around with the undocumented ProPresenter API. I say undocumented because it is not officially offered as a way to access ProPresenter data and control it. Some people have done a great job at figuring out how ProPresenter sends data over the network between their apps which allows us to extend the software to meet unique needs. Basically, by using websockets, we can interact with ProPresenter which will return JSON-formatted data reflecting information about songs in the library, playlist, the index of the current song, the current slide and next slide information, etc.
I created a local Node.js project and in just a few hours, I had something ready to alpha test! My approach was to have a web browser open on the local network that could poll and listen to changes from ProPresenter, and then relay that new data to a web server. That web server would then relay those changes to all of the connected clients, much like a chat server would send a message to everyone.
I showed it to my team, but the idea was tabled for awhile because we thought it through and didn’t want people buried in their phones while singing. However, as we got closer to the event, we realized that the two TV screens we rented might not be sufficient, and I was asked to work on this again.
As I was preparing this for production, I discussed briefly with our IT team about setting up an internal server running Node.js that could be accessed on port 80 (the default HTTP port) outside the firewall, but bandwidth, security and performance for hundreds of clients connecting through the Internet all at the same time was a concern. With that in mind, I turned to Amazon EC2.
If you haven’t heard of it, Amazon Elastic Cloud Computing (EC2) is basically virtual servers “in the cloud” (i.e. remotely and accessible from the internet). It’s not too hard to set up, and they even have a free tier available for 12 months, so you can try it out for free! I had never used it before this project, so I actually followed a tutorial to help me get it going.
Once I had my Linux server set up on Amazon EC2, I assigned an “Elastic IP” (Amazon’s term for a type of static IP), and then I bought a domain name, fglyrics.com, for $12 and tied it to that IP. It was up and online in minutes. I installed Node.js on my new server, copied over my code, and started it running.
About the software:
I call the software Presentation Bridge, because it acts as a “bridge” or connector between the presentation software and all of the clients.
When you first load the Bridge page, you have two options: Configuring your ProPresenter connection, and Connecting to a Bridge. In order to connect to ProPresenter, you have to enable the network settings. It relies on both the “remote” and “stage display” controls to get all of the data needed.
When connecting to ProPresenter in Presentation Bridge, you’ll need to supply the local ProPresenter IP address and port, as well as the control password and local library path. This is what allows the Bridge to pull all of the slide images and other information. This is standardized across all of our ProPresenter installs at our church, so it’s always the same path for us. It should be the full, absolute path from the root of your drive.
When you’ve successfully connected, the gray dot at the top of the ProPresenter config box will turn green. If there’s an error, it will turn red. Status information is displayed in a log area further down the screen.
To connect to a bridge, choose one from the dropdown list. If it is configured to have a control password, you’ll have to enter that in order to connect. Adding bridges and making changes to existing bridges can be managed by clicking the settings wheel. It supports multiple bridges, which I added as a feature since we have multiple auditoriums and may want to use more than one simultaneously.
As the operator runs ProPresenter, the slides will be displayed on the Bridge screen with the currently selected slide showing a blinking red border, so it is clear which slide is currently being displayed. You can browse the playlists and items in the playlist. You have the option to send the current data from ProPresenter to the server (or turn it off), turn on a logo (configured in Bridge settings, useful if you’re currently not connected to ProPresenter, etc.). I also implemented the NoSleep.js library which will attempt to keep any connected mobile devices awake.
On the viewer/client side, I implemented three types of “listeners”:
Text Listener – just gets text data and displays it as big as possible on the screen
Image Listener – displays the actual slide image by using a base64 encoding of the slide
Stage Display – recreates the current slide/next slide layout
All three listeners can be accessed through the browser. The data is relayed from the server using the socket.io library. I tested it on my iOS devices, Android devices, and even my Amazon Fire TV stick on multiple browsers and they all work really well. Across an internet connection, the moment a slide is clicked in ProPresenter, that slide is visible on the listener devices.
We used it during our Night of Worship this year and it worked great! I used a hotspot for the Bridge connection and then everyone connected to the Text Listener using the internet connection on their own phones. It uses very little data since it is just a text stream, which is really nice!
Overall, I enjoyed creating this software for our unique need. I plan to extend the functionality down the road as I have time, including attaching “triggers” to specific slides as they are activated, to send RossTalk messages, fire HTTP cues, etc. on the local production network.
If you’d like to try Presentation Bridge out for yourself, the code is freely available on my Github repository. You can also request to demo it using my live site running on Amazon EC2. I wrote the software to support multiple bridges at a time, in case you have multiple meeting spaces or venues that need to run simultaneously. When more than one Bridge is enabled and running, any users that connect are presented with a drop-down list and can select the Bridge they want to join.
I spent some time this past week writing and testing support for ProTally with Blackmagic ATEM switchers. I didn’t have one to develop with, and after posting on a discussion group about the software, a new friend sent me a unit to work on. Thanks again, Kyle!
Version 1.2.0 now supports:
Blackmagic ATEM switchers – it will auto discover any ATEM switchers on the network, or you can manually type in an IP Address as well
Ross Carbonite Black, Carbonite Black Solo, and Graphite switchers
And I now have a Windows release build in addition to a MacOS release build!
Awhile back, I wrote about the on-screen tally software I recently developed. We needed a way for our CG operators to know when their source was on-air or about to be on-air. I won’t rehash the definitions or inner-workings again, so if you didn’t read that first post, I recommend you read that before this.
I had hoped to give a release build much sooner but lost time waiting on some other people to test it in their environments. We’ve been running it in our environments for almost 2 months now with no issues, so I finally gave it some final polishing and bug squashing to get it ready for release. The interface has changed some, and for now, you can choose between a generic TSL 3.1 device or, specifically, a Ross Carbonite. (Not a Carbonite Black, Solo, or any of the other models.) Why specifically that model? Because I have two of them, and that’s what I know and use!
I hope to add support for the Blackmagic ATEM protocol soon. I need to connect with someone who has one, so if that’s you and you’re interested in testing with me, drop me a line!
And this should go without saying, but even though I’ve made software to augment your use of software like Renewed Vision’s ProPresenter and other products, it is in no way associated with any company or product. This is distributed under the MIT license and is available for anyone to use without cost.
I wrote a new piece of software recently that I’m really excited about. It’s called ProTally and it is designed to display video tally markers directly on the screen.
What’s tally? In broadcast setups, it is often helpful to be able to tell camera operators, computer graphics workers, etc. when their shot is being used on-air or visible on screens. Most broadcast equipment comes with some sort of tally light that, when connected to the right system, lights up to let the operator know.
With today’s broadcast equipment, a lot of this tally information can be communicated directly over the network, in real time using a variety of protocols. One particular protocol is TSL UMD, from Television Systems Limited for Under Monitor Displays. It is supported by a wide variety of broadcast industry equipment and allows the devices to know the tally state of one another.
In church environments where we use computer software like ProPresenter to send CG content to a video switcher, it can be very helpful to have a tally light that the user can see so they don’t accidentally change a graphic while it is live or on the screen. While there are a variety of external tally lights available for this purpose, I wanted to design something that would allow for a green (in preview) or red (in program/on-air) box directly on the screen that the user can easily see while operating the software, without having to purchase additional hardware.
For this project, I used Node JS and the Electron libraries, along with an existing Node JS module that acts as a TSL 3.1 Protocol server. I was able to whip up a demo in just a few short hours. Then it was just a matter of finessing and adding features.
Using ProTally, you can monitor up to 4 Tally Addresses using TSL UMD 3.1 and keep track of their Preview, Program, and Preview+Program states. You can even customize the colors as needed! The boxes can be resized and moved around on the screen and those positions will be saved and recalled the next time the software launches.
I decided to add options to allow the user to choose whether they wanted a filled-in box or a transparent box with a color border. It also reads the label data and stores that as it comes in, to give names to the tally addresses. And, because we use two Carbonite switchers at my church, I also wrote in an object array that uses the TSL UMD protocol implementation described by Ross here: http://help.rossvideo.com/carbonite-device/Topics/Devices/UMD/TSL.html
Due to some limitations of the Electron framework, I had to make the windows appear “always on top” of other windows, to ensure they would be visible while clicking around in ProPresenter (or ProVideoServer or whatever software being used). This can be a little annoying if you’re using the computer for another task and don’t want to see the tally boxes, so to help with that, I added a “Hide All Boxes” option that can be used rather than quitting the software.
Here is ProTally in action:
This solves a problem for a lot of people who want on-screen tally for ProPresenter, ProVideoServer, or whatever software they may be using. You can even use it to monitor general inputs like cameras, etc. Just assign the tally address, position the box, and you’re set!
I will have this available in my GitHub repository soon. Feel free to check it out and if you use it, let me know how you like it! I plan to add more features to it as I have time.
A few months ago, I picked up this nifty device called a Stream Deck made by Elgato Gaming. It’s a 15-button USB keyboard with LCD buttons. It’s primarily marketed towards gamers who live stream so they can have quick access to commands and functions as they stream. The programmer in me couldn’t resist trying it out to help us with our production setup.
Using the base software provided, I was able to fairly quickly implement a workflow to allow volunteers to have easy access to buttons that then fire commands on our Ross Dashboard Production Control ecosystem. If you’ve not used Dashboard before, you can read about how we use it at my church here. It’s fairly easy to set up a custom panel in Dashboard that runs an HTTP web server at a specific port, which in turns allow you to “click” a button on the panel by calling that button’s trigger ID remotely via a specific URL.
Using the “URL” method provided in the base software, we are able to make web calls to the Dashboard custom panels to fire the commands. All the logic/code remains in Dashboard, and this just becomes a method of executing those commands remotely via an HTTP request.
We used the base software for a few months without issue, however quickly realized the limitation of not being able to have bi-directional communication between our Dashboard Production Control and the individual Stream Decks. For example, several of our commands act as “toggles”, meaning we can have a few different state options that represent the current status of a device. If I only had one person making changes or operating the system, it wouldn’t be a huge issue. That person would hopefully remember what button they pressed last. However, when there are a lot of moving parts and multiple people controlling systems, the ability to update status on all devices becomes very helpful.
Enter NodeJS. People smarter than me took the time to write a base NodeJS library to control the Stream Deck. I hadn’t written in NodeJS before, but being a programmer, I was ready to learn something new. I downloaded and installed all the necessary libraries, IDE, etc. and quickly whipped up some code using the base library to control our stream decks. In just a few hours, I had something operational and started running it from the command line. I then spent a couple of weeks refining it and now we have a fully functional, self contained app that can run on Mac, Windows or Linux. It’s packaged using the Electron libraries made freely available with the Node platform.
My controller software uses a base JSON file which defines the button structure of the stream deck. This makes it very flexible and expandable as our needs grow as I can just modify the JSON file to change the button structure.
The software then parses that JSON and builds the buttons on the Stream Deck in real time. If a button has a trigger action assigned, the command is sent to the corresponding device. I’ve written support for several protocols, including the Dashboard Web Call, RossTalk (good for sending messages to your Ross equipment), OSC, VideoHub routing, and more. You can even do internal stuff like jumping from one button page to another, changing button images during actions, etc. Each button can support an unlimited number of button actions, which I called triggers.
It also supports defining a set of devices, so if there’s a device you want to send messages to often, you can define the device in a separate file along with its host, port, type, etc. and then only refer to that device in the button structure. That way, if any of those related variables change, you only have to change it in one place.
The software also runs a basic TCP listener server on a specific port, and this is where the bi-directional communication comes into play. Anytime a command is run on the master Dashboard Custom Panel Production Control, it relays a message to the remote Stream Deck via the TCP listener and updates the state of the button.
This means that we can run commands from any originating location, whether it is the web-based production control (that I’m still developing), one of the remote Dashboard panels that connects to Production Control, one of the Stream Decks (we currently have 2 of them, one in each control room), or even the Master Control panel and every device will receive an updated status.
I also added a “Virtual Deck” option, which allows you to operate the software with or without having a physical Stream Deck attached. You can also choose to have the Virtual Deck operate independently of your physical Stream Deck, so it’s like having two decks in one!
I am making this software freely available to anyone who can benefit from it. My hope is that the local church can make use of this to allow their volunteers to more easily operate tech equipment during services.