Adding Footswitch Control to Clearcom

As I said in a previous post, we rely heavily on our Clearcom intercom system to have good lines of communication between all of the tech team and the band as well.

In each control room, we have a “director’s station” which has a 4-channel intercom where he/she can talk to all four channels of the intercom system: the tech team in Auditorium 1, the band in Auditorium 1, the band in Auditorium 2, and the tech team in Auditorium 2. All other intercom stations are single channel and that person can only talk on the particular channel they are wired for.

For the most part, this works great and does well to keep intercom chatter down and keeps the director as the funnel of communication. However, I have found that quite often, when we are doing smaller events in our smaller auditorium, that I am sitting at the video switcher with no way to talk to the band without having to get up and go sit at the director’s station behind me.

When our integrators built out the AVL for our new auditorium, they installed a Clearcom RM-702 2-channel rack mounted intercom into the rack room for Auditorium 2. I found that after a year and a half, we never use it there, so I decided to move it to Control Room 2, which is the video control room that drives operation for Auditorium 2.

Photo Jul 17, 2 52 42 PM
This is the RM-702, installed now into the control room.

As I operate the video switcher, I like to keep my hands on the switcher (and my streamdeck!). Reaching over to press an intercom talk button is an interruption to my workflow. The nice thing about the RM-702 is that it has an accessory port, which allows you to connect a footswitch to activate the talk channels!

photo-jul-17-2-50-21-pm.jpg
Here is a view of the accessory port with the cable connected that I purchased.

The accessory port is a DB-15 connector, so I bought an extension cable, along with a DB-15 plug. I bought these from Amazon:

I also bought two Yamama FC5 foot pedals.

photo-jul-17-2-52-59-pm.jpgTo wire everything up, I had to cut off the plug at the end of the pedals to expose the wires. The wiring is pretty simple. Clearcom has it well documented what the pinout is.

  • Pin 1: Ground
  • Pin 2: Talk Channel A
  • Pin 9: Talk Channel B

 

photo-jul-17-4-24-10-pm.jpg
Here is everything wired up.

The Yamaha pedal is a contact/no-contact switch, so it doesn’t matter which color wire goes to which pin.

 

Once I connected everything up, I realized that the Yamaha pedal works the opposite of what I needed: it was making contact when the pedal wasn’t pressed down (shorting the connection in the Clearcom, keeping the talk channel turned on) and then when I would press the pedal down, it would break the connection, turning the talk channel off.

I opened up the pedal and modified the two leads so that it would make a connection when pressed down. I basically just swapped the position of the two copper bands.

Photo Jul 19, 8 29 25 AM

 

Photo Jul 19, 8 29 46 AM
This is how the pedal looks like by default. It is connecting the two wires until you press down, which breaks the connection. The opposite of what I needed.
Photo Jul 19, 8 50 31 AM
By swapping the two leads, now I have a pedal that only makes connection when pressed down. I had to bend them a little bit to sit properly.

Voila! Now I have two footpedals that I can use to talk on either channel, hands-free! The next step will be labeling them and then taping them down to the floor.

 

Photo Jul 19, 9 20 06 AM

All in all, this was a very inexpensive improvement. The pedals were about $15 each and the cable/adapter was about $10, and the project was simple.

 

On-Screen Tally Light for ProPresenter using software

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.

icon_512x512@2x

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.

Screen Shot 2018-07-11 at 10.31.00 PM

Screen Shot 2018-07-11 at 10.32.26 PM

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

Screen Shot 2018-07-11 at 10.31.31 PM
The software stores the label names of the devices as they are read in the tally data over time, so as the software runs longer, this drop down list becomes mnemonicly helpful.

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.

Screen Shot 2018-07-11 at 10.30.45 PM

Here is ProTally in action:

 

Screen Shot 2018-07-11 at 10.35.13 PM
This is a transparent window with a border sitting on the output window of ProPresenter.

 

 

Screen Shot 2018-07-11 at 10.33.51 PM
This is a filled-in box.

 

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.

Customizable Clock and Countdowns for Production, in a Web Browser

Accurate clocks and countdowns can be a huge help when it comes to keeping services and productions on time. In our control rooms, we use these clocks:

943

They’re made by a company called ESE and they are basically network-based POE-powered NTP clocks. Because they are synced to NTP (Network Time Protocol), they are all in sync to the exact same time down to the second. We like them because they are big and grab your attention. We have them mounted above the multiviewers in each control room along with a couple of others in the actual tech booths out in the auditoriums.

But what about everyone else, like the band or people on stage? We don’t have clocks like this where they can easily see. And, the ESE clocks just tell the time, they don’t count down to a specific time.

I decided to do something about that. We have a server in the video rack room that has a video out connection into the video systems. It’s just a simple output of the secondary monitor. So, I figured it would be pretty easy to display a clock in a browser, and run it full screen on that secondary monitor, that feeds into the video router where I can then easily send it to any screen in the system that needs it.

I found some examples online and eventually came across this article where someone had created a full screen clock: https://www.nayuki.io/page/full-screen-clock-javascript

clockThis computer’s time is synced to NTP, so it stays in sync with the clocks in the control rooms, too.

I quickly decided to take this a step further and incorporate some countdowns. I had a couple of self-imposed restrictions though:

  1. I wanted the countdowns to be customizable as our needs change, not just always count down to the same date/time.
  2. I didn’t want to run a web server just to accomplish this, in order to pass new data to the locally running page/JavaScript.

I decided an easy method would be to have a separate JavaScript file that defines some countdown data, and include that in my main clock page, and just refresh the page to get the new data. I set the page to reload every 30 seconds by putting this in the <head> of the HTML:

<meta http-equiv="refresh" content="30">

I want my volunteers to be able to easily change this countdown data, without having to know JavaScript. Time for Dashboard! My directors have a Dashboard Custom Panel that I created for them which they use every week. It has a myriad of control options for them, so it was simple to just add another tab for the new countdowns.

countdowns_

Dashboard has a built in date picker and time picker, which makes it super easy.

I added two options in addition to the date and time, publish time, and expire time.

countdowns_publishtime
I limited it to these few options, between 2 minutes and 7 days. This determines when the countdown will appear on the screen.
countdowns_expiretime
When a countdown expires, it turns red so it grabs your attention.

When the user clicks, “Update”, it runs a simple function that grabs all of this data, writes the JavaScript into a string, and then saves that into a file using the ogscript.saveToFile function. The file is saved to a common Dropbox folder that the server running the web page clock has access to.

countdowndata

clock-and-countdowns.png
Here it is in action. The countdowns automatically update when the page reloads every 30 seconds.

 

I’ve made the files available on my Github, if you can benefit from them! We will be giving this a trial run on Sunday.

Remote Control of Panasonic AW-HE40 PTZ Camera through Dashboard

We have a Panasonic AW-HE40 located in each auditorium at my church to allow the control room operators to see the space. We also occasionally use them as on-screen cameras since they have HD-SDI outputs. The quality is surprising for the size of the device.

aw-he40swpj_2_1024_0

The cameras come with a fully functional webpage that allows you to control them.

Screen Shot 2018-06-12 at 9.26.40 AM

By peeking around at the code some, I was able to figure out how to send HTTP requests to change presets of the camera.

Here is my Ross Dashboard custom panel that allows our volunteers to quickly pull up presets:

 

Screen Shot 2018-06-12 at 11.41.45 AM
The panel allows the user to see the camera’s viewing angle and select a pre-defined preset. Presets can be modified within the existing web interface for the camera. A Setup tab is also available to configure the IP address of the camera you wish to control.

 

If you use my panel, you’ll still need to manage/modify the presets using the existing interface. We don’t change our presets often, so I didn’t feel the need to recreate any other functionality than recalling presets.

I’ve made this panel available on Github here if you can benefit from it: https://github.com/josephdadams/RossDashboardPanels

Getting A List of Active Users in Unity Intercom

At my church, we use Unity Intercom to expand our wired intercom system. It is very useful to have users who can be mobile and still stay in communication.

We wanted to have the ability for our directors to see who is currently logged into Unity without having to log into the server or be logged into a Unity client on a device.

After doing some digging and consulting the forums, I found out that if you go to this address:

http://unityserverIPaddr:20101/userconfig

The Unity server will return a JSON dataset of the server information including the list of users.

"users":[{"username":"josephadams", "title":"Joseph Adams", "allowedrcv":"63", "online":"0", "notify":"yes", "locksettings":"no", "lockchannels":"no", "groups":[{"groupNumber":"0", "transmit":"63", "receive":"63"}]},{"username":"technician", "title":"FG Tech User", "allowedrcv":"63", "online":"0", "notify":"yes", "locksettings":"no", "lockchannels":"no", "groups":[{"groupNumber":"0", "transmit":"9", "receive":"63"}]}]

Once you’ve parsed that JSON into objects, you just have to check if the “online” property is 0 (false) or 1 (true) and you now know who is logged in!

I added this to our director’s dashboard so now they can easily see who is available.

Screen Shot 2018-06-12 at 9.10.05 AM

It’s great when we can extend software like this! I wish more software developers exposed REST API’s for their users. Great job, Unity!

Controlling Aja Ki Pro in Ross Dashboard

I’ve had a few people ask about my custom panel in Ross Dashboard that controls Aja Ki Pro recorders using their built-in RESTful API, so I thought I would write a quick post about how that works.

AJA has done an excellent job of creating an accessible device with their API. The web browser interface is great and you can edit or control nearly every aspect of the device from there. The main reason I created the Dashboard interface was to limit that control and simplify the use for volunteers who may not want to get into the complexity of it all.

Screen Shot 2018-06-11 at 12.30.33 PM

 

Screen Shot 2018-06-11 at 12.30.46 PM
This is a screenshot of the built-in web interface of the Ki Pro.

 

Their RESTful API takes simple parameters as querystrings and returns JSON data that can be easily parsed for the results and manipulated.

For example, if you make this request:

http://kiproIPaddr/config?action=get&paramid=eParamID_TransportState

You will get a response like this, showing the current transport state of the Ki Pro:

{"paramid":"2097217802","name":"eParamID_TransportState","value":"1","value_name":"Idle"}

My panel in Dashboard just takes advantage of this API to make all of the requests to get and set the data. By using a timer function, I am also able to keep the Dashboard panel in sync with the physical state of the actual Ki Pro deck, which is helpful in case someone manually presses a transport button or otherwise makes a change.

 

Screen Shot 2018-06-11 at 12.21.30 PM
The setup tab is fairly basic, you can set the IP address of the Ki Pro and default video/audio input options. The API itself supports many more changes, so if you need to change those options more often, the panel could be modified to support that.
Screen Shot 2018-06-11 at 12.22.26 PM
Full transport control as well as custom clip names, changing slots (drives), etc. This will follow the state of the actual Ki Pro and update itself if the Ki Pro is armed or changed outside of the Dashboard panel.

 

 

Screen Shot 2018-06-11 at 12.34.35 PM
Here is a screenshot of one of the functions that gets the current transport state.

 

If you are interested in everything the Aja Ki Pro API supports, you can get a list of all available parameters by going to:

http://kiproIPaddr/descriptors

I hope this is helpful! If you would like to download my custom panel, it is available on Github: https://github.com/josephdadams/RossDashboardPanels

Custom Reports in Planning Center Online

If you work or serve in a church, chances are you use Planning Center Online a lot. We use their Services product to plan and organize our weekend services, schedule volunteers, etc.

Even though they have a mobile app and desktop interface, we still rely on printed reports on the weekend. It’s simple, fast, we don’t have to worry about the internet going down, the team members can write all over them, etc.

Out of the box, Planning Center comes with some great reports that you can print out. They can somewhat tailored to your organization with your church’s name or logo, etc.

Screen Shot 2018-05-02 at 8.33.53 AM
Here’s an out of the box standard report. It gets the job done but it could be better.

In addition to their standard reports, they also support custom reporting. If you know a little HTML, CSS, and are ready to learn some custom tags, it’s pretty easy to jump right in.

Screen Shot 2018-05-02 at 9.29.14 AM
Here is a screenshot of a custom report. You can see the HTML and CSS, along with the custom tags that help to generate the report. You can see that some variables have been created and are then referred to later in the document.

The reporting language that PCO uses is called Liquid. If you want a good resource to read that is outside of what PCO offers, here is one.

Liquid is an open source templating language that allows you to do simple conditional and iteration along with filters to parse and control the page as it loads. What this means for you as a user is that you have a lot of simple power at your fingertips to create custom reports designed for exactly what you need!

So, with these tools, I have created several custom reports that our teams use when it is time to print out paperwork for weekend services.

The report I use most often is for our tech team. It prints out a customized version for every person serving on the team that weekend, with their name, the general service flow, and information just for their position, notes, checklists, etc.

 

Screen Shot 2018-05-02 at 8.35.16 AM
Here is an example page from the report. Every team member gets a page (or pages as needed) with their name and customized information for their position.

 

The nice thing about this report is that I only have to run it once and print once. It creates a new page for every person on the team, so I don’t have to remember how many copies I need to print – I just print the whole file and it has exactly what each person/position needs!

This report includes custom plan item notes per position. To add those, just add a plan item with an item note named:

Position Name

The name has to match exactly. The report also includes overall plan notes per position. To add those, just add plan notes like this:

Team Name – Position Name

When you add your plan notes or plan item notes, just type something specific in that field and only that position will see it when it prints. We like this a lot on our teams because it keeps the report looking a lot simpler for those who don’t need all the extra detail.

One thing you may not have noticed is that I include checklists, customized for each position on the team. We have found checklists to be very helpful so we don’t miss any of the mundane stuff, especially when volunteers may only be serving once a month.

If you use my custom report file, all of the checklist code is already created for you. You just need to create the Plan Note fields to correspond with each position. Each position that has a checklist item should have a Plan Note Field like this:

Checklist – Team Name – Position Name

Any item in the list that begins with a “*” (asterisk) will be printed in a “DURING REHEARSAL” section, and only printed once. Any item that begins with a “~” (tilde) will be printed in an “AFTER EACH SERVICE” section for each service time and will include a small blank line for notes. Any other item will be printed in a “BEFORE SERVICE” section and will be printed once for each service time.

So, for example, a plan note in the field “Checklist – Tech Team – Stage Manager”:

*Take out trash

This would only print one time in the checklist, in the “During Rehearsal” section. You can edit the report to rename that header if you’d like.

~Shut all doors

This would print multiple times, once for each service time, in the “After Each Service” section.

Check for presentation

This would print multiple times, once for each service time, in the “Before Each Service” section. This is likely going to be the most-used field, so it is the one with the simplest formatting requirements.

I like to keep all of my checklists in a Template Plan (with no other items or people) within PCO, and just import them each week to the plan before printing. This allows me to update the checklists from time to time without hardcoding it into the report file, and I can customize it per-plan if needed.

I hope this is helpful to you! You can download all of my custom reports here: https://github.com/josephdadams/PlanningCenterServicesReports/