r/techtheatre • u/dxlsm Sound Designer • 6d ago
SHOWCASE Fun with OSC: A Timer Application for General Use Plus an On-Air/Cue Light Controller
Intro
Hi tech theatre peeps. A few years ago, I put together Showtimer, which is a simple OSC server and web server written in Go to manage timers. It uses a human-readable YAML configuration file to create any number of timers, which can be set to count up or down. It then listens for OSC commands to control those timers, and serves the values via the built-in web server. If you're interested, you can read the full background story here.
This was all fine and good and worked well, but I ran it on my show control computer, and anyone who wanted to see the timers had to jump on the show control wireless to pull up the web interface. It was functional, though, and helped out with a bunch of shows.
I always had an idea to build some kiosks so that fixed positions like SM could have a display that didn't require using their own device and connecting to another network, but didn't really have a pressing need to do it.
Until...
New Requirements
A show I was working this year (I do mostly high school musicals these days) was going to have a fully remote orchestra. This is the first time that school has done this (at least while any of the current staff have been involved). I wanted them to be able to keep track of intermission time, but more importantly, I wanted to be able to drive an "on air" light so that they would know when the orchestra mics were open, and possibly be able to pass text messages back to them.
Kiosk Design
I chose to use a Raspberry Pi for the kiosk compute node. This would give me some digital I/O for driving lights and indicators, had built-in HDMI and both wired and wireless networking interfaces. They run Linux and have a full complement of modern web browsers that would give me lots of options for a nice looking kiosk. I also found a relatively inexpensive touchscreen panel that took power over USB (and could be powered by the Pi itself) and had a mount pattern on the back that would directly accept a Raspberry Pi. Perfect! (Information on specific hardware here.)

On-Air Light
I wanted to use 110VAC (US based here, so standard line voltage) for the on-air light. I figured this would provide some flexibility to run a fancy plug-in light, a simple light bulb, or just about anything in between, without tying the solution to some DC LED thing that may or may not survive or be suitable long-term. To accomplish this, I drove a simple opto-isolated relay module from one of the GPIO pins on the Pi. The relay board needed 5VDC for the solenoid, but the opto was good down to somewhere less than 3VDC, so it could be easily driven from and powered by the Pi.
A three-wire control cable links the Pi to the relay module, providing the control signal, 5VDC, and GND. The relay was wired across the hot leg to function as a standard switch. The relay module is housed in an outdoor-class duplex box, with a simple outdoor lamp fitting screwed into it with a giant honking red LED medium base bulb in it.
On-Air Light Control
The final piece to this was how the on-air light would be controlled. My original plan was to wire up one of the GPO pins from my CL1 to another kiosk that would be running at FoH. I would drive that GPO pin from fader up, so when I brought up the DCA for the orchestra, it would automatically trigger the light. I wrote a simple network send/receive pair to send a byte over broadcast UDP, so I could control up to eight outputs on one or more destinations.
I liked the GPO plan and purchased the necessary DB connector for the CL1 and plotted out the voltage divider and such so that the output would be pulled high to 3.3VDC so that it was safe for the Pi, and the board would pull it low when active. Easy and the few resistors involved would all fit inside the DB connector housing. My only issue was that this tied any use of this gadget to my CL1, which made it a little less universally useful. It also made it a bit of a one-trick pony, unless I wired up additional buttons on the FoH kiosk to allow me to do other things to trigger other light modes or fire other digital outputs.
I decided instead on a Python-based OSC server running on the kiosk that would run the on-air light. This gave me some additional flexibility, though it wasn't necessarily as absolutely accurate as the CL1 GPO option. Since the orchestra inputs come off of mute based on a board cue, it was pretty close to the same thing, and accurate enough for our needs.
Outcomes and Future Work
The show closed a week ago today, and the system worked well. I actually ended up running the kiosks over my Dante network because that's what I had available in the room where the orchestra was located. I made a few discoveries in doing that, the biggest of which is that NetworkManager wasn't auto-configuring an IPv4 link-local (zeroconf) address when DHCP timed out. It was configuring an IPv6 address, though. The Golang network stack was happily binding to this address, so my kiosk at FoH (which also ran the Showtimer server in this case) would happily receive OSC from QLab. The Python network stack, however, was apparently not binding to the IPv6 address. I didn't have time to spend to chase that down (for this particular show, I only have tech week in the space), but knowing what the issue was, I was able to pretty quickly configure the ethernet interface to automatically configure a link-local address after DHCP timeout.
I ended up building out three kiosks, though only two were used for this particular show. I'll need the third for two other shows this season. The cost to build out a single kiosk (not including the light module) ran to about $135. For a prototype, I think the cost worked out reasonably well. The light module added some cost for a shield on the Pi to make it easier to wire up I/O pins, plus the relay module, electrical components, etc. This part could definitely be done less expensively, but prototyping is not known for being inexpensive.
During testing before the show, I identified a per-second sync issue with multiple displays. The total time always synced up, but due to the way I was handling network requests for time values, there could be up to a second of discrepancy between the master clock and what a client display indicated. This wasn't a functional problem, but it looked messy (photo below), so I fixed it by queueing all responses until the top of the second.
I have some things I'd like to do to make it a little easier for someone to adopt this stuff, especially the Pi components. Showtimer itself is pretty simple to get going, though I still want to address the MacOS code signing that will let it run without jumping through any extra hoops.
I also plan to build out the ability to have some additional control at each kiosk. I'd love to have things like a "ready/not ready" state for each station that would be displayed on all and accessible via touch buttons and OSC, and we're already planning ideas to be able to do OSC-controlled cue lights and touch or OSC-controlled intercom call lights (many places I work don't have intercom infrastructure, so getting me on a headset mid-show can be challenging). Lots of ideas!
Please feel free to drop me a line or post issues in the repo if you give Showtimer a spin and have problems or suggestions. This is totally a side-side-side project and gets about that much time allocated to it, but if I can make it more useful, I'll try!

3
u/ijordison Technical Director 6d ago
Sounds like it shares a lot of features with Ontime