Controlling Planning Center LIVE with a Stream Deck

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.

IMG_9032
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:

  1. 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
  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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.
  7. 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!

IMG_9035
The PCO Live module in action!

Using a Stream Deck as a Production Controller, Revisited

One of my first posts on this blog detailed how I wrote software in Node.js to interface with an Elgato Stream Deck to control some of our production equipment, interfacing with the video switchers, router, Ross Dashboard, etc. It’s time to revisit that.

We’ve been using my controller now every week in our control rooms and tech booths for about a year. My team loves it. It integrates into our centralized production workflow, where each deck sends commands to a central Dashboard panel, which runs the command, and then sends out updates to all the connected stream decks.

However, I haven’t had much time to make it a better product for other people. I wrote support for the Stream Deck Mini when that was released, but that’s about it. I haven’t had time or cause to do much else with it. So, for that reason, I wanted to share with you a piece of software that is under constant, active development: Bitfocus Companion.

Screen Shot 2019-02-15 at 10.43.46 AM

 

Companion is written in Node.js and packaged in Electron just like my product, so it can run on Mac, Windows, or Linux. But it can do so much more than my controller! One of the best features is that it has a web-based management interface, so you can add actions to buttons easily and on-the-fly. It supports a ton of production equipment and chances are good that your gear is already on the supported list, or, perhaps someone can create a module for it.

I was asked to join the development team recently for Companion, so I’ve started making some modules for Companion to integrate with software and gear that we have. I’ve created a module for Interactive Technologies’ CueServer, which we have in a couple of our venues here.

Screen Shot 2019-02-15 at 10.54.05 AM
Here are some actions you can perform on a CueServer now with the module I created for Companion.
Screen Shot 2019-02-15 at 10.53.53 AM
An example of a key down action for triggering a CueServer macro in Companion.

If you use ProTally, my on-screen tally box notification software, and want to integrate with Companion, I made a module for that too! Make sure to go download the latest ProTally release which supports this feature! With Companion, in addition to Preview and Program windows, you can also send a Beacon, which flashes at a custom rate and color. Check this video out for a demo:

Both of these modules are available in the bleeding edge builds of Companion and will be included in the next stable release soon.

So, if you’re looking for a great production controller that integrates with the Stream Deck, go check out Companion! It’s only going to get better from here!

 

Elgato Stream Deck as Production Controller

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.

elgato-strream-deck-boxshot-tecs
The Stream Deck sells for about $140.

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.

Screen Shot 2018-05-01 at 8.16.41 PM
Here is a screenshot of the base software provided by Elgato. It’s very functional as is.

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.

1024x1024
This was the quick icon I whipped up for the software.

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.

Screen Shot 2018-05-01 at 8.25.25 PM
Here’s an example screenshot of one of my button files, written in JavaScript Object Notation. This allows me to add or remove buttons very easily and also programmatically.

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.

Screen Shot 2018-05-01 at 8.17.40 PM
The app runs completely in the tray with a simple context menu.

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.

screen-shot-2018-05-01-at-8-18-05-pm.png
The settings menu allows you to choose the button/device files you want to use as well as whether the TCP listener service and notifications are turned on.
Screen Shot 2018-05-01 at 8.18.13 PM
A sample notification that can appear when a button is pressed. You can determine which triggers sent notifications.

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!

Screen Shot 2018-05-01 at 8.17.26 PM
Here is a screenshot of the Virtual Deck in action.
Screen Shot 2018-05-01 at 8.18.26 PM
Here is what some buttons that have been toggled look like on the Virtual Deck. It’s very clear to see the current state of those buttons!

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.

It’s currently up on GitHub here: https://github.com/josephdadams/StreamDeckProductionController

I’ve only built a Mac binary, but you can easily package it for Windows or Linux if needed.

I am working on an Editor function right now that will allow you to add/edit buttons without having to write them in JSON, but until then, you’ll have to make do with that option. Here’s a good tutorial on learning JSON if you need help: https://www.codecademy.com/courses/javascript-beginner-en-xTAfX/0/1

If I can help you out along the way, don’t hesitate to reach out!