If you haven’t read about my Tally Arbiter project, you can read about it here and here. Today I’m excited to release version 1.3 which offers some exciting new features!
First, Tally Arbiter Cloud! Now you can send tally data from your local instance of Tally Arbiter to a server in the cloud. Anyone can connect to your cloud server without having to tunnel into your private production network. And, if you are doing remote production with switchers in multiple physical locations or networks, each location can run an instance of Tally Arbiter and the cloud server can aggregate all of the data together in real time! All you need in order to make a connection is a Cloud Key provided by the local client that matches on the server. Keys can be made and revoked at any time.
I’ve set up an Amazon EC2 instance running Ubuntu, with Tally Arbiter running on it. I set a cloud key and set up a cloud destination on my local server to send the data to the server running on EC2. Now, I can log into my EC2 server’s Tally Arbiter web interface and view the tally data from anywhere without having to VPN to the church network. This will make it easy for volunteers to use their personal phones to view tally without having to be in the private network.
Here is a video to show it in action:
Second, Feedbacks and Control through Bitfocus Companion on your stream deck! Companion 2.1 is out now, and if you run the latest build, you can use the new “TechMinistry Tally Arbiter” module to view live tally data from Tally Arbiter on any button on your stream deck. It also supports the ability to “flash” any connected listener client.
Third, a new tally listener client – the M5StickC! This is an inexpensive Arduino ESP32 “finger computer”. A friend of mine in the UK recommended this to me for a possible integration with the project. I bought mine off Amazon for $20 but you can buy them directly from the manufacturer for less than $10. It is a portable, easy-to-use, open source, IoT development board.
Programming this thing was fun because the code is all in C++ which I haven’t used since high school. The power of websockets and the socket.io protocol means that this microcontroller can connect to my Tally Arbiter server and communicate the same way any of the other listening clients do.
Here’s a video to show how it works and how to program one:
Version 1.3 of Tally Arbiter also comes with some other perhaps less exciting but still helpful updates:
All Settings, REST API, and Producer page now require a Basic Auth username/password to access.
In the settings or producer page, if you mouse over the preview and program boxes, Tally Arbiter will show you which sources currently have that device in that bus
The settings page will now show the number of device sources and device actions assigned to a device in the list.
Sources will now attempt to auto-reconnect if the connection is lost with a max retry of 5 times.
Lastly, I’ve set up a website for this project to help others who want to share about it. You can access it at: http://www.tallyarbiter.com
My hope is that this project enables churches and any organization who needs tally for their productions be able to attain it at a lower cost. I’ve put a lot of hours into developing this free software. If it is helpful to you, please let me know!
A few weeks ago, I released some free tally light software to the community. I’ve had people checking it out and I am excited to be able to offer some more features!
Some highlights in the 1.1 release:
Overall performance improvements
Fixed an issue where Devices added during runtime did not obtain a proper initialization state and would not assign tally data properly until the server was restarted
Fixed an issue where Devices mapped to OBS Studio sources could not correctly be in both preview and program bus at the same time (when in Studio mode)
Better checking on Source connection states
TCP/UDP ports are now verified as in-use or reserved to help eliminate user errors
More verbose logging in the server console
All tally data received by all Sources is now sent to the Settings page (while open) for logging and diagnostic purposes
New Producer page; allows users to view all device states (tally information) without having the Settings page open. Created in dark mode for in-service viewing
Documentation added to Settings page to assist in initial setup and learning
OSC added as a Source type to trigger tally states
OSC added as a Device Action type (supports multiple arguments)
“Python” client renamed to “blink(1)” in preparation of other types of listener clients that may also use Python
Version is now displayed on the Settings page for diagnostic purposes
Now, I am releasing version 1.2! The highlights:
Newtek Tricaster support now included as a tally source type
OBS can now properly discern whether it is in preview or program
Support for TSL Clients – Tally Arbiter can now send all device states (derived and arbitrated from any source type) as TSL 3.1 (UDP or TCP) out by specifying a TSL Address for each Tally Arbiter Device. This can be used to drive UMDs and other tally receiving interfaces by acting as a protocol converter between all source types and TSL.
New Python listening client – GPO Output! Now you can trigger just about anything using the GPIO ports on a Raspberry Pi.
Bug fixes and UI improvements
More documentation and upgrade instructions
The biggest feature in this release is the new TSL Clients functionality. Tally Arbiter can now send out TSL 3.1 data to any number of connected devices any time a device changes state within Tally Arbiter. So, you can have, for example, a multiviewer of one switcher dynamically show whether a camera is in use on that switcher or a switcher of an entirely different brand/model by using Tally Arbiter as a protocol converter.
Here’s a video to show how the new TSL Clients feature works within Tally Arbiter and how to integrate it with a switcher like the Ross Carbonite. In this example, tally data is coming from both a Carbonite and a Blackmagic ATEM and the Carbonite multiviewer reflects that in real-time.
I’ve written a fewdifferent times about Planning Center Online and how we use it at my church. I thought I would share a video walkthrough of how to set up custom checklists for positions as well as our latest custom matrix report.
Update: Version 1.2 is available now; read about it here:
At my church, we have two auditoriums, each with their own video switcher and cameras. All of the inputs and outputs of each switcher are on a common video router, so all of these sources can easily be shared across both rooms. However, even with all this, we have no camera tally system. Commercial tally systems can be expensive, and it’s just something we’ve never been able to afford.
It’s not normally an issue, but sometimes we want to pull up a shot of a camera in Auditorium 1 and show it in Auditorium 2. Because we have no tally system, the camera operator would not know their shot was being used. And, even if we did have a tally system, those systems generally only interface with one tally source/switcher, not multiple sources at the same time.
A few weeks ago, I was quarantined from work due to a co-worker testing positive for COVID-19. I set out to use this time to write a tally system for our church to use. Now that we’ve re-opened for church services, we will really need this, because we will have cameras capturing the service to stream online, but won’t necessarily have those cameras visible on the projector screens in the auditoriums during that time, where the operators would at least have a visual reference if their shot was in use.
And, because we have two video switchers, I needed to come up with a solution that would allow either video switcher to pull up a camera in either auditorium in Preview or Program, and make sure the operator still knew their shot was in use.
So here is Tally Arbiter. I called it this because the software aggregates tally data from multiple sources and “arbitrates” whether that device is in Preview, Program, or both across all sources and buses.
I played Halo a lot back in the day. A LOT.
The server software is written in Node.js and can run on a Raspberry Pi. It supports the TSL 3.1 network protocol like what our Ross Carbonite switchers use, but I’ve also written support for Blackmagic ATEM switchers, OBS Studio, StudioCoast VMix, and Roland SmartTally. I plan to one day add support for incoming webhooks, and GPIO inputs for switchers that don’t have network-based protocols.
The settings page of the Tally Arbiter server.
The software supports tally data coming from multiple sources, and each source can vary in protocol type. This could be useful, for example, if you had shared cameras for your production on-screen using an ATEM and also through your live stream using OBS or VMix, and you need the cameras to reflect the tally data of either system.
You can configure multiple devices in the software. These would be what generally receives tally data, whether it be cameras, CG stations, monitors, etc. Each device can support addressing from multiple sources. This is the “arbitration” portion of the software.
Once a device is determined to be in preview and/or program, device action(s) can be run. This can be sending out a TSL 3.1 protocol message (to a monitor/scope/multiviewer), an outgoing webhook (to tell another device to start playing a video (“roll clip”), for example), triggering a relay if you have CCUs that need contact closures to turn on the tally lights, or even local console output for logging and testing.
I bought a project box, put the relay in, ran some CAT5e cable I had laying around and connected it to the relay and the CCU’s with custom DB25 connectors. I had to modify the project box some because I wanted the relay to sit flat in the box, so I used a dremel to remove the bottom of the middle screwposts, which weren’t really needed anyway. Never be afraid to modify something to make it work!
The relay fits snugly inside this box. This particular unit has 8 relays, so I could add 2 more cameras with preview/program tally control to this unit.The box and the Pi running the server fit nicely on top of one of the CCUs.A clean rack is a happy rack!Preview and Program lights!This will make our camera operators happy.
But what about the cameras we use that don’t have tally lights? For these, I decided to use Raspberry Pi Zero W‘s that would run software listening over websockets to the Tally Arbiter server. These particular Pi models are inexpensive and simple to use. I knew that I could get the least expensive cost for physical tally lights out of these Pi’s if I went the GPIO route with some LED lights and custom circuitry, but I wanted to design something that people who may not be comfortable with these concepts could easily implement. And honestly, the thought of soldering something just sounded like something I’d have to possibly maintain down the road. So, I used the blink(1) USB lights by ThingM.
I first started experimenting with these USB lights about a year ago when I created a silent notification system for our band to use in case we had a tech issue during a service. The company that makes these has published very easy to use APIs, which makes it a great tool to use with custom software.
I like this simple black case from Vilros. You can get the whole kit minus the SD card for about $30 on Amazon.Here’s a blink(1). A pretty versatile device!
The listener client script is written in Python since that programming language runs so easily on the Raspberry Pi OS no matter what model Pi you have. And, since we are using the socket.io websocket libary, bi-directional real-time communication between the server and clients even though the programming languages vary is not an issue.
I used a USB extension cable to bring the light up by the camera, but the Pi is down on the floor of the platform.Another view.
All together, each wireless tally light should cost between $55 and $60 depending on what Pi case you use, SD cards, etc. Tally Arbiter has no built-in limitation of the number of wireless clients that can be connected, so this makes it a very versatile and flexible system no matter what the size is of your production.
Lastly, I also created an option to view live Tally data in a browser, like on a tablet or phone. You can select the device from the list and the background of the page will be red, green, or black depending on that device’s tally state.
The web based tally option is nice if you need a quick portable tally option.
The web tally is controllable through the Settings page just like any other listening client, so you can reassign the tally remotely and even send a flash to that client to get their attention.
Here’s a walkthrough video of the whole system in action:
As usual with my projects, I’ve made this open-source and available for your use on Github: http://github.com/josephdadams/TallyArbiter. It is fully documented with a REST API if you want to automate use of it outside of the GUI that I have created. There are also step-by-step instructions on how to set up a Raspberry Pi Zero, with OS imaging and all of of the libraries and script installing needed to get it going.
My hope and passion is to see resources like this to be used to further the Gospel. I believe and have seen that God can use technology for His good, and when we can use it to further ministry, that is how we can see the Gospel spread.
If these projects are helpful to you and your church, let me know! I love hearing how you use technology to serve the church.
Just thought I would share a quick custom panel that shows how to send OSC from Ross Dashboard to other devices.
If you’re not familiar with OSC (Open Sound Control), you can read about it here. Essentially, it is a protocol used for real-time communication between (typically) media devices, synthesizers, etc. It has grown to be used by a wide variety of software for remote control purposes.
To send a message, first a byte array must be constructed. In Dashboard, the easiest way to do this is to use a messageBuilder object and then convert it to a byte array at the end.
function createOSCMessage(cmd, val, varType)
{
var messageBuilder = ogscript.createMessageBuilder();
var len = cmd.length+1;
var pad = (4 - len%4)%4;
messageBuilder.writeString(cmd);
// put null terminator at end of command string
messageBuilder.writeChar(0); // null terminator
// pad end of command string with nulls
for (var i=0; i<pad; ++i)
{
messageBuilder.writeChar(0);
}
This creates the message builder object, inserts the OSC command, and then pads the rest of the bytes with nulls. The command byte must be a multiple of 4, so the pad is calculated.
Next, the type (float, int, or string) is determined and the value applied:
// set the 4 bytes that identify the format
messageBuilder.writeChar(',');
if (varType == 'float')
{
messageBuilder.writeChar('f');
messageBuilder.writeChar(0);
messageBuilder.writeChar(0);
messageBuilder.writeFloat(val);
}
else if (varType == 'int')
{
messageBuilder.writeChar('i');
messageBuilder.writeChar(0);
messageBuilder.writeChar(0);
messageBuilder.writeInt(val);
}
else
{
messageBuilder.writeChar('s');
messageBuilder.writeChar(0);
messageBuilder.writeChar(0);
messageBuilder.writeString(val);
}
return messageBuilder.toByteArray();
}
The resulting byte array is returned to the function that called it.
To send a float:
function sendOSCMessageFloat(ip, port, cmd, val)
{
ogscript.sendUDPBytes(ip, port, createOSCMessage(cmd, val, 'float'));
ogscript.debug('OSC Float Sent');
}
var host = '127.0.0.1';
var port = '12321';
var oscCommand = '/command/float';
var oscFloat = 1.1;
sendOSCMessageFloat(host, port, oscCommand, oscFloat);
To send an int:
function sendOSCMessageInt(ip, port, cmd, val)
{
ogscript.sendUDPBytes(ip, port, createOSCMessage(cmd, val, 'int'));
ogscript.debug('OSC Int Sent');
}
var host = '127.0.0.1';
var port = '12321';
var oscCommand = '/command/int';
var oscInt = 1;
sendOSCMessageInt(host, port, oscCommand, oscInt);
To send a string:
function sendOSCMessageString(ip, port, cmd, val)
{
ogscript.sendUDPBytes(ip, port, createOSCMessage(cmd, val, 'string'));
ogscript.debug('OSC String Sent');
}
var host = '127.0.0.1';
var port = '12321';
var oscCommand = '/command/string';
var oscString = 'TEST';
sendOSCMessageString(host, port, oscCommand, oscString);
That’s it! Pretty simple using the message builder and byte array.
I love automation. I love making things more efficient and consistent, and I’ve found that on a particular level, automating or simplifying certain tasks through automation can make it easier for volunteers when working in a church production environment.
The latest app that I’ve been enjoying is the iOS “Shortcuts” app that was added to my phone in a recent iOS upgrade. It allows you to use actions within apps or activity on your phone to spawn other actions. Things like “Text my wife how long it will take me to get home, when I leave work” by using the GPS location on my phone. Or, make a shortcut that when you take a picture using the camera app, it is automatically posted to Facebook.
Look for this app on your iOS device.
If you’ve ever used the service IFTTT, you’ll find familiarity with the Shortcuts app in some of the concepts. Of course, the integration into the phone at a core level with Shortcuts is much nicer. One thing I particularly like is that, once you name a shortcut, you can simply say, “Hey Siri, [shortcut name]” and it will run it.
And, Shortcuts can make HTTP requests (GET, POST, with JSON, etc.) as actions. So, it’s super easy to add a shortcut that triggers a Companion button or a task in a Ross Dashboard custom panel, for example. And that’s one of the ways I’m using the Shortcuts app.
In our production workflow, we use Ross Dashboard custom panels that I created to control nearly every aspect of our video system (and slowly, audio and lighting as I create the connections). It’s very easy to trigger a button via HTTP request, so I set up several shortcuts that I can use to save me time, especially when I am away from the production area or not near a computer running one of the Dashboard panels, as long as my phone is connected to the production network wifi (or I’m connected via VPN if remote).
Here are a few of the shortcuts I’ve created.
All this particular shortcut does is make an HTTP GET request to my master Ross Dashboard Custom Panel, which is listening to Port 5400, and triggers the GPI, “aud1_psl”.
It’s the same as clicking on this yellow button, but I can run it from my phone, as long as I am connected to the production network!
So, just like that, it’s very easy to do something like this: “Hey Siri, go to Pre Service in Auditorium 1”, and have all of the lights change (by sending a midi-relay command to a MIDI Show Control message to our Vista lighting console) and the program screens go to the pre-service loop (by sending a RossTalk command to execute a custom control on the Carbonite to change inputs).
Here’s a video of it in action!
[wpvideo URjPHb4M]
Go check out the Shortcuts app if you aren’t using it already in your production workflow!
Back in the summer, I posted about a project I had recently finished, which involved sending HTTP requests to a server that would then relay a MIDI output message based on the request that was sent.
We’ve been using that software (dubbed midi-relay) since then to be able to control our Chroma-Q Vista lighting desks remotely across vlans by using stream decks running Companion. It works pretty well, especially since the midi-relay software is configured to run directly on the lighting consoles upon startup. We have even set up a few crontab entries to send CURL commands to the light desks to turn them on at certain times when we don’t want to be on-site just to press a button.
In anticipation of completing my most recent project, “LiveCaption“, which takes audio and transcribes it to text in real-time, I started working on midi-relay 2.0: listening to MIDI input and using that to trigger a response or action.
I figured it was time this thing had a logo.
In both auditoriums at my church, we have Avid S6L audio consoles. These consoles can do a lot, and like most consoles, they have GPIO pinouts to allow you to trigger things remotely, whether as an action originating from the sound console, or externally that then triggers something on the console like recalling a snapshot, muting an input, etc.
Stock photo of the console I found on the Internet.
These are (some of) the I/O pins on the S6L console. It has GPIO and MIDI ports. We use the footswitch input for setting tap tempo.
I started looking at the possibility of using the GPO pins on the console to trigger an external action like sending an HTTP request to Ross Dashboard, Companion, etc. However, there are only 8 GPO pins on this audio board, so I knew that could be a limiting factor down the road in terms of the number of possible triggers I could have.
The S6L also has MIDI In and Out, and through the Events section of the console, it can be used as either a trigger (MIDI In) or an action (MIDI Out) on just about anything.
The Events page on an Avid S6L console. All kinds of things can be used as triggers and actions here! In this particular event, I’ve created a trigger that when the Snapshot “Band” is loaded, it sends MIDI Out on Channel 1 with Note 22 (A#0) at Velocity 100. MIDI-Relay then listens for that MIDI message and sends an HTTP POST request to the LiveCaption server to stop listening for caption audio.
We already have a snapshot that we load when we go to the sermon/message that mutes things, sets up aux sends, etc. and I wanted to be able to use that snapshot event to automatically start the captioning service via the REST API I had already built into LiveCaption.
In the previous version, midi-relay could only send Note On/Off messages and the custom MSC (MIDI Show Control) message type I had written just for controlling our Vista lighting consoles. With version 2.0, midi-relay can now send MIDI out of all of the channel voice MIDI message types:
Note On / Note Off
Polyphonic Aftertouch
Control Change
Program Change
Pitch Bend
Channel Pressure / Aftertouch
It can also send out:
MSC (MIDI Show Control), which is actually a type of SysEx message
Raw SysEx messages, formatted in either decimal or hexadecimal
And, midi-relay can now listen for all of those channel voice and SysEx messages and use it to trigger one of the following:
HTTP GET/POST (with JSON data if needed)
AppleScript (if running midi-relay on MacOS)
Shell Script (for all OS’s)
There are a few software and hardware products out there that can do similar things, like the BomeBox, but I wanted to build something less-expensive and something that could run on a Raspberry Pi, which is exactly how we’ve deployed midi-relay in this case.
Here is the Raspberry Pi running midi-relay, connected to the MIDI ports on the S6L via a USB to MIDI interface. It tucks away nicely at the back of the desk.
Now we can easily and automatically trigger the caption service to start and stop listening just by running the snapshots on the audio console that we were already doing during that transition in the service. This makes it easier for our volunteers and they don’t really have to learn a new thing.
The documentation is pretty thorough if you want to use the API to send relay messages or set up new triggers, but you can also use the new Settings page running on the server to do all that and more.
From the Settings page, you can view available MIDI ports, add/delete Triggers, view detected midi-relay hosts running on the network, and send Relay messages to other hosts.
And if you’re a Companion user for your stream deck, I updated the module for Companion to support the new channel voice MIDI relay messages as well! You’ll need to download an early alpha release of Companion 2.0 to be able try that out. Search for “Tech Ministry MIDI Relay” in Companion.
Here’s a list of the Raspberry Pi parts I used, off Amazon:
I hope this is helpful to you and your projects! If you need any help implementing along the way, or have ideas for improvement, don’t hesitate to reach out!
For awhile now, I’ve wanted to be able to offer live captions for people attending services at my church who may be deaf or hard of hearing, to allow them to follow along with the sermon as it is spoken aloud. I didn’t want them to have to install a particular app, since people have a wide variety of phone models and OS’s, and that just sounded like a pain to support long-term. I also wanted to develop something low-cost, so that more churches and ministries could benefit from it.
I decided to take concepts learned my PresentationBridge project from last year’s downtown worship night and use it for this project. The idea was essentially the same, I wanted to be able to relay, in real-time, text data from a local computer to all connected clients using the Node.js socket.io library. Instead of the text data coming from something like ProPresenter, the text data would be the results of the Web Speech API’s processing of my audio source.
If you’re a Google Chrome user, Chrome has implemented W3C’s Web Speech API, which allows you to access the microphone, capture the incoming audio, and receive a speech-to-text result, all within the browser using JavaScript. It’s fast and, important to me, it’s free!
Here is how it works: The computer that is doing the actual transcribing of the audio source to text must use Google Chrome and connect to a Bridge room, similar to how my PresentationBridge project works. Multiple bridge rooms (think “venues” or “locations”) can be configured on the server, and if multiple rooms are available, when end users connect, they will be given an option to choose the room they want to be in and receive text. The only requirement for browser choice is the computer doing the transcribing; all others can use any browser on any computer or device they choose.
This is the primary Bridge interface that does the transcribing work.
From the Bridge interface, you can choose which “Bridge” (venue) you want to control. If the Bridge is configured with a control password, you will have to enter it. Once connected, you can choose whether to send text data to the connected clients, go to logo, etc. You can redirect all users to a new webpage at any time, send a text/announcement, or reload their page entirely. To start transcribing, just click “Start Listening”. You’ll have to allow Chrome to have access to the microphone/audio source (only the first time). When you are connected to the Bridge, you can also choose to send the users to Logo Mode (helpful when you’re not broadcasting), or you can choose to send data or turn it off (helpful when you want to test transcribe but not send it out to everyone). There is also a simple word dictionary that can be used to replace commonly misidentified words with their proper transcription.
A note about secure-origin and accessing the microphone:If you’re running this server and try to access the page via localhost, Google Chrome will allow you to access the microphone without a security warning. However, if you are trying to access the page from another computer/location, the microphone will be blocked due to Chrome’s secure-origin policy.
If you’re not using a secure connection, you can also modify the Chrome security flag to bypass this (not recommended for long-term use because you’ll have to do this every time Chrome restarts, but it’s helpful in testing):
Navigate to chrome://flags/#unsafely-treat-insecure-origin-as-secure in the address bar.
Find and enable the Insecure origins treated as secure section.
Add any addresses you want to ignore the secure origin policy for. Remember to include the port number (the default port for this project is 3000).
Save and restart Chrome.
Here is a walkthrough video of the captioning service in action:
[wpvideo r6P0iWGj ]
I chose to host this project on an Amazon EC2 instance, because my usage fits within the free tier. We set up a subdomain DNS entry to point to the Elastic IP so it’s easy for people in the church to find and use the service. The EC2 instance uses Ubuntu Linux to run the Node.js code. I also used ngninx as a proxy server. This allowed me to run the service on my custom port, but forward the necessary HTTPS (port 443) traffic to it, which helps with load balancing and keeps my server from having to handle all of that secure traffic. I configured it to use our domain’s SSL certificate.
I also created a simple API for the service so that certain commands like “start listening”, “send data”, “go to logo” etc. can be done remotely without user interaction. This will make it easier to automate down the road, which I plan to do soon, so that the captioning service is only listening to the live audio source when we are at certain points in the service like the sermon. Because it’s just a simple REST API, you can use just about anything to control it, including a Stream Deck!
We deployed them in our two auditoriums using ChromeBooks. An inexpensive solution that runs the Chrome Browser!
In order to give the devices a direct feed from our audio consoles, I needed an audio interface. I bought this inexpensive one off Amazon that’s just a simple XLR to USB cable. It works great on Mac, PC, and even ChromeBooks.
XLR to USB audio interface so we can send a direct feed from the audio console instead of using an internal microphone on the computer running the Bridge.
At my church, we have two venues where we run worship services simultaneously. This means that when I am running reports and printing paperwork for all the teams, there’s a lot to print! Using the PCO custom reporting tool is great because it saves so much time.
If you didn’t read Part 1 where I first talked about this, hop on over and check that out.
Lately, rather than printing reports one at a time with each plan, I’ve been using the matrix view in Planning Center to view multiple plans at once and print reports all at the same time.
The matrix view in PCO is very powerful and helps when you want to look at several plans at once.
My custom matrix report is similar to the normal plan report, but this one supports multiple plans, obviously. It loops through every plan, and then every position in the plan (based on the teams I have chosen), and then generates a sheet for that position, customized with their checklists, notes, etc.
My most recent edit includes a custom array for sort order, because the default is to print the position reports alphabetically. Rather than rename my positions, I opted for the custom sort.
The print order array can be customized so that reports are sorted in the order you want.
This saves time every week because now they print out in the order I need to pass them out!
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.
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!
[wpvideo ZvMtBNPa]
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.
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.
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.
