Back in May, a month before the end of school, the school’s art department had planned a live stage show which incorporated drama, visual arts, film, music, and dance. This was the first live performance after several years of public health measures which prevented live audiences and large gathering so, suffice it to say, everyone was excited. I was a core member of the Tech Team which managed all the technical parts of the performance and really enjoyed the experience. So, here I am writing about the music and projection part of the performance.

To provide some background, none of us had any formal theater training, and our school isn’t very big on theatrical performances, so a lot of this was new and experimental for us. I’ve had interest in technical theater for some time now and decided to take some ideas from there, namely the idea of cues. Essentially, a stage manager calls out cues (in our case, numbers) to people responsible for lights, music, etc. who then “take” the cue, performing the necessary transition in lights, music, etc. This makes a single person responsible for the timing of the show, but also makes it far simpler to organize, and even more importantly change parts of the show.


This might seem like a super simple setup: just drop some files in a folder and double click them to play as necessary. To be honest, that likely would have worked and been good enough, but I wanted something that better fit this list of objectives I held in my head:

  • Simple UI: if nothing goes wrong, the entire show should be possible by pressing a single key when cued.
  • Adaptable: if something does go wrong, skipping, stopping, restarting, reordering should be trivial and asynchronous (i.e. it should be possible to do so without stopping all playback).
  • Flexible: it should support music, videos, and a combination thereof at the same time.
  • Reliable: it should play music and start videos with minimal latency and without failure or crashes.

So that music-in-a-folder approach may be adaptable and reliable (depending on chosen media player), but the UI is certainly not simple. You’re nearly guaranteed an extra window opening and a method to navigate between the current and next piece requiring either a mouse or the arrow keys. Also, playing a song and a video at the same time could get complicated. Again, this is probably good enough, but maybe there’s a better approach?

Linux Show Player

I don’t quite recall how I came upon Linux Show Player — likely while exploring open source cueing or playlist software — but it happened to be exactly what I needed, and not much else: perfect! Here’s the main UI:

Main list view of Linux Show Player containing a standard navigation bar, list of cues, list of playing tracks, and media actions per-track or globally.

I won’t describe all the features of Linux Show Player here, but I’ll highlight a general overview and our setup — that’s what this post is about after all.

The main section is, of course, the cues, named however you like, which reference audio files (or commands, keep reading) to play. It comes with default numbering, but we added our own because they did not always match our cues. The currently playing tracks are marked with a green circle and shown in the right sidebar, and the little arrow to the left of cue #5 indicates the following cue, #6, will activate at the same time as it. An impossible-to-miss “GO” button starts playing the highlighted track, as does the space bar. It also moves the highlight to the next song to play that next. This perfectly fits my simple interface criteria and the live show really worked like that: a friend merely pressed the space bar when cued!

The other UI buttons pause/resume, stop, interrupt (fade-out, then stop), fade in, or fade out either the track or all tracks if using the top-right corner of buttons. The icons are simple, clear, and have help text when hovered over. Also, as per my adaptability requirement, the cues can be dragged around and modified while letting playback continue.

After setting it up, the main features proved reliable enough for a live performance, so it was time to see whether Linux Show Player was flexible enough to also handle videos.


At the time of setting up for the performance, and at the time of writing, Linux Show Player does not yet support video cues1, but there were several parts in the performance where videos had to be projected on a screen or the stage, once at the same time as music. Specifically, that’s the aforementioned cues #5 and #6, where #6 is a short video to be played for the first part of the dance with music cue #5.

This requirement was why integrating the projection solution with our music solution was ideal (alongside minimizing the number of tools in our setup). Though really, having the audio embedded in the video file as with the other video cues (#0-3) would have done just fine; I just wanted to display the music in Linux Show Player’s sidebar which does not happen for videos.

Similar to the music, the simplest solution, and the one used every other time, is simply opening a video in any video player, dragging the window to the projector’s display, and unpausing. Again, this is good enough, but it would be a bit more professional to not have audience members seeing the entire process of starting a video.

Here, the keen-eyed of you might ask: why not just close/turn off/freeze the projector until the video is ready? First off, the projector is several meters off the ground, unreachable without blocking audience members. Also, our projector takes a while to start and displays dialog during startup and shutdown. Freezing the projector on a black screen is indeed an option, but it requires a person peeking out the side of the curtain or sitting near the front of the stage, in front of the audience. There’s also no feedback, if I recall correctly, to the person controlling it, so we wouldn’t know if the screen was frozen until the video was displayed. To be clear, this may just be the case with our projector. I’m sure professional-grade equipment has much better controls.

But so what was the solution for the non-existent video cues? It’s command cues:

This type of cue allows executing an arbitrary command so all that’s left is finding a good player, with the definition of “good” being:

  • Low Latency: once a cue is called, we want the video to play with as little delay as possible.
  • Minimal UI: ideally nothing at all, just the video, fullscreen.
  • Configurable: which display the video opens on should be configurable.

My everyday media player actually already fit this description, so I stuck with it.


mpv is an amazing, open source, cross-platform, media player. It plays music and videos in a wide range of formats, all in a super minimal, but oh-so-configurable, player. It also comes with an IPC server to control playback and the ability to stay open after playing a file. Here’s the full config used for the show:

osc=no           # disable the video player UI (playback progress, etc.)
fullscreen       # start fullscreened
fs-screen=2      # use the second display (the projector)
keep-open=always # don't quit the entire player after playback ends
idle=yes         # don't destroy the player window after playback ends
reset-on-next-file=pause # reset the pause state (unpause) when a new file
                         # is loaded
input-ipc-server=/tmp/mpvsocket # enable the input IPC server to allow
                                # controlling playback externally

Much of this comes from the Linux Show Player wiki, as well as the command cue config2 below:

MEDIA="..."; printf '{ "command": ["loadfile", "%s"] }\n' $MEDIA|socat - /tmp/mpvsocket

With this, the video file specified in $MEDIA is loaded and immediately played by mpv which is already running on the second display, all controlled by Linux Show Player.


That’s really it: two programs which made up our entire music and projection setup for the show. Is this how it’s done professionally? Probably not, but it worked for us. My laptop’s audio output was connected to a soundboard where I mixed the music and microphones. The projector was connected through HDMI and some long distance HDMI-ethernet-HDMI converter boxes. Lighting was also done with cues and controlled by a friend on the school’s ETC ColorSource 20.

The lead up to the live show was very stressful and somewhat disorganized, but the tech ran without a hitch. I thoroughly enjoyed this experience, learned a lot, strengthened friendships and made some new ones, and will certainly miss it as I go off to university. Good luck to next year’s tech team, maybe you’ll even base your setup on mine :D

  1. ↩︎

  2. The purpose of a separate MEDIA environment variable instead of putting the path directly in to the IPC string is to make it easier to go through multiple cues where the path is right at the start. ↩︎