Controlling Chroma-Q (Jands) Vista with MIDI Show Control and a Stream Deck using Node.JS and the Web MIDI API

Posted on June 6, 2019 by techministryblog

At my church, we use Chroma-Q’s Vista lighting platform (formerly owned by Jands). It’s a great platform and easy for volunteers to execute pre-programmed lighting cues. Every large worship space we have on campus with a lighting system runs some version of Vista, whether on a physical console or a PC.

We generally program our lighting to use one or two cuelists and volunteers just advance cue by cue within that list for the service. It’s pretty straightforward and works well for them.

Sometimes, we need the ability to advance cues in a list remotely, when we’re not near the lighting console, and that’s where this latest project began.

Most lighting consoles can be controlled using some form of MIDI command. Older ones require a physical connection, others can use network connections. By using a loopback/virtual port, Vista can receive both MIDI notes and MIDI Show Control commands.

A lot of people have been able to accomplish this type of remote control over the network using a protocol called RTP-MIDI. This protocol is very easy to use and computers can broadcast/discover each other over the network, so it makes it a lot quicker to get up and going.

Screen Shot 2019-06-06 at 3.44.05 PM

This is great, and I’ve used it, but I wanted to design something particular for our needs. (1) I wanted something I could run on any PC or Mac to accept commands from a wider range of sources, and so many devices nowadays can send HTTP requests. (2) I wanted something that primarily triggered over TCP, because while RTP-MIDI is great and fast, it uses UDP traffic that can’t cross vlans/subnets. TCP traffic easily can.

So, I broke this project down into two parts: a server that listens to HTTP requests and relays local MIDI, and a module for Companion that allows the Stream Deck to send requests to that server. The server is flexible to support other devices that may want to trigger it, and the Companion module is perfectly paired to work with it.

The server runs a simple REST API that returns a list of local MIDI ports and can accept Note On, Note Off, or MSC (MIDI Show Control) commands. It accepts JSON data via HTTP POST which is then used to build the hexadecimal data and send the MIDI commands.

The HTTP side of things in Node.js uses the Express framework. The MIDI side uses the Jazz Soft JZZ.js library.

The server runs directly on the Vista computer to relay the MIDI commands on a virtual MIDI port which Vista is listening to.

Here is a video of it in action!

If you want to do this yourself, setting up the Vista side of things is pretty straightforward.

First, if you are using Vista on a PC and haven’t already, downloaded LoopMidi, you can get it here. It’s free software that creates a virtual MIDI port on the PC.

Once that is configured, open Vista and go to the MIDI settings in User Preferences.

Screen Shot 2019-06-06 at 1.41.54 PM.png

Under the MIDI tab, select the External MIDI port “LoopMidi” (or whatever you named your port). If you’re going to be using MSC, be sure to make note of the Device ID you select.

If you want to advance a cuelist using MIDI Note On commands, right click on the cuelist and under the MIDI tab, select the Note you want to send for the “Play” command.

Screen Shot 2019-06-06 at 1.42.24 PM.png

I hope this is helpful for you! You can dowload a binary release of the MIDI-Relay server from my Github. It’s available for Mac, Windows, and Linux. The Companion module will be made available in a release build at some point.

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

Posted on April 19, 2019 by techministryblog

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.

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.

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.

ProTally 1.7 with support for Roland Smart Tally!

Posted on March 29, 2019March 28, 2019 by techministryblog

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.

maxresdefault

118170-lamroland2-3-org

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:

http://[ipaddress]/tally/[tally address]/status

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.

Screen Shot 2019-03-28 at 2.34.47 PM — This simple Python script made testing a lot easier!

This feature has been released, so you can go get it now up on the Github repo!

Controlling a Roland V-60HD video switcher with a Stream Deck and Companion

Posted on March 28, 2019May 9, 2019 by techministryblog

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.

rol-v-60hd — This is the Roland V-60HD video switcher.

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:

\u0002CUT;

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.

Screen Shot 2019-03-28 at 2.12.50 PM.png — You can see some of the options available for the module in this screenshot.

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.

Sending automated reminders via a Slack webhook, AppleScript, and Launchd on MacOS

Posted on March 18, 2019 by techministryblog

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.

Screen Shot 2019-03-07 at 9.40.27 PM

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.

Screen Shot 2019-03-18 at 9.22.16 AM.png — This is the file that MacOS will look at to schedule the script to run.

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!

This is what the alert looks like on my phone.

I hope this helps you! If you want any of the scripts, they’re up on Github.

Controlling Planning Center LIVE with a Stream Deck

Posted on February 28, 2019 by techministryblog

In my last post, I mentioned a great tool, Companion, that integrates with the Elgato Stream Deck. I’ve had the opportunity to write a few modules for it to extend its control capabilities, like controlling a CueServer, or my own software, ProTally.

If you work in tech for a church, chances are that you use or have at least heard of Planning Center Online to manage your worship services and people. PCO has a feature for their Services product called Services LIVE that allows you to designate where you are at in a service flow while a service is ongoing, which updates anyone who may be watching. It also records the times so you can look back later and see things like “Did that song we said would take 5 minutes actually take more like 6 minutes and 30 seconds?” It’s a very useful tool.

The interface to advance a LIVE plan, however, has not been the best for our volunteers. Even within the PCO app, the buttons to advance a plan to the next item are rather tiny, and some of my team have trouble knowing whether or not they hit the button.

This is the standard PCO Live interface. The small double arrows at the bottom left and right of the screen are the controls. Our volunteers have a hard time pressing these.

One thing that makes Planning Center Online great is that they love developers, and they’ve made a very extensive Application Programming Interface (API) available for anyone to use. This means you can get access to your service and plan data without having to actually click and browse the website.

I delved into that API this past week and used it to create a new module for Companion. One of the caveats of using the API is that in order to advance a live plan, you have to know both the service type ID and the plan ID. This requires traversing the API data some and making multiple requests. If you’re a programmer, this makes sense. If you’re just an end-user, it may not be as straightforward. So, I set out to make something easy enough for anyone to use.

Here is a walkthrough video on how the module works:

What it actually does:

When you first load the module and supply it with the authentication tokens, it requests all of the available service types and stores that internally.
```
https://api.planningcenteronline.com/services/v2/service_types
```
Then it asks for the next 7 upcoming plans for each service type based on the list that was just retrieved. This is then used to build the drop down list so you can choose your plan.
```
https://api.planningcenteronline.com/services/v2/service_types/${serviceTypeId}/plans?filter=future&per_page=7
```
When you send a “Previous” or “Next” command, it first asks for the LIVE information for that selected plan.
```
https://api.planningcenteronline.com/services/v2/service_types/${serviceTypeId}/plans/${planId}/live
```
It checks for who the current controller of the plan is, and compares that to an internal variable in Companion that represents the owner of the authentication token.
If the current controller is null, a command is sent to toggle control to the token owner, and the returning value of the current controller is stored in that internal variable so we know who “we” are for next time.
```
https://api.planningcenteronline.com/services/v2/service_types/${serviceTypeId}/plans/${planId}/live/toggle_control
```
If the current controller is not null, a toggle command is sent to release control of the plan to no one, and then a toggle command is immediately sent again so that control is toggled to us. The reason for this is that if our authentication key is not the current controller, the API will return an error when we try to advance the plan.
Now that we know we are in control, the current controller value returned by the API is stored as an internal variable, and then the next or previous command is sent to advance the plan.
```
https://api.planningcenteronline.com/services/v2/service_types/${serviceTypeId}/plans/${planId}/live/go_to_next_item
```

Because Node.js is an asychronous programming language, all of this is done through Promises, which is similar in concept to a callback function, however it allows for cleaner and easier to read code.

So, stay tuned for this module to become available in the next stable release of Companion, and if you’re willing to try it out in development mode, it’s available now!

Support for blink(1) now available in ProTally!

Posted on February 26, 2019 by techministryblog

I wrote ProTally last year so our volunteers running ProPresenter could know when their source was on screen or about to be on screen. It has been very helpful in minimizing our mistakes by making distracting graphic changes while on-air. It supports tally data from our Ross Carbonite switchers but I’ve also written support for the TSL 3.1 protocol, Blackmagic ATEM switchers, OBS Studio scenes, and most recently, Bitfocus Companion.

I recently picked up a blink(1) to test out for another project I’m working on. If you’ve not heard of it, the blink(1) is a small $30 USB device with LEDs built in, designed to give you a quick-glance notice of anything on your computer. The creators have made libraries in several popular programming languages, like Node.js (the language ProTally is written in), to interact with it.

I decided to get my feet wet and learn about the device’s capabilities by integrating it with ProTally. Since ProTally can read and work with tally data from so many different types of sources, that means it’s already primed to take that tally data and act on it in different ways, not just on-screen.

So, I am pleased to announce, that ProTally now supports up to 4 blink(1) devices that can mirror the color the user chooses for an on-screen tally box. The user can choose between showing the tally color on a box on their monitor (like normal), a connected blink(1) device, or both. If you are using multiple tally boxes but don’t own an equal number of blink(1) devices, you can also choose to share the blink(1) across multiple tally boxes, and the higher box will get priority.

The latest release of ProTally supporting blink(1) devices as tally lights is available on Github now, so go check it out!

Tech Ministry