Another in the #techbodgery series on using technology (on a budget!) to deliver features typically usually found in big venues to smaller theatres and entertainment venues.

Today, we visit Prompt Corner, and look at how to make our SM (Stage Manager)'s life a little easier (a happy SM makes for a better show, trust me!)

The old joke goes "Q: What's the difference between an SM and god?, A: God doesn't think they're an SM" but the Stage Manager is ultimately responsible for everything in the theatre from the moment the house opens until the curtain falls, they cue every lighting change, sound effect, set move etc from "prompt corner" (usually the Stage Left wing)

In order to do that efficiently they are often surrounded, in larger venues, by a plethora of monitors showing various cameras and other information, alongside a comms system, cue lights and much more.

Show Relay Cameras

Some theatres have many cameras showing the fly floor, wings, auditorium, musical director / conductor, band pit etc etc but we have two (which I generally consider the bare minimum); a full-colour view of the stage from the front of house lighting bar position, and an infrared camera from the back of the house that shows the stage (and area immediately in front of it) in complete darkness.

Cue View

I also love the excellent (and free!) Cue View software. This shows the current cue and status of our QLab (for sound and video) and Eos (for lighting) systems, immediately answering the question "what cue are we in?" or "did that run?"

We are, however, a very small venue and somewhat pressed for space, especially in the wings. A sea of monitors is neither efficient nor practical, and more often than not we end up with things displayed on our SM's iPad or MacBook balanced on top of the desk.

The view our SM sees (note that this QLab and LX file are not for the show shown here!)

Enter the Raspberry Pi

The Raspberry Pi (4, the 3B was sadly not powerful enough for this to work) is my goto for projects like this (basically anything an ESP can't do!) but I must admit that the move from X11 to Wayland and a few other changes has made it harder than it should be!

Firstly, I started from a simple CLI-only version of Raspbian and enabled auto-login (to shell, not GUI) with raspi-config and installed x11 (not wayland) and Xephyr with apt.

Xephyr is a simple tool that creates a 'virtual' X11 display that's a subset of the display itself, using this allows us to divide a screen into sections and then run apps 'fullscreen' inside each of them.

Edit your ~/.profile file to have the following on the end of it;

# Start X11 Automatically
if [[ -z "$DISPLAY" ]] && [[ $(tty) = /dev/tty1 ]]; then
    . startx
fi
~/.profile

And a simple ~/.xinitrc sets up the three virtual displays (one for Cue View, and one for each camera), it also uses pm2 (which is overkill and intended for NodeJS  scripts - although works with anything - but I like it, and makes it easy to amend the config and restart anything that crashes) to start each of the scripts in /home/pi/scripts 

xset s off
unclutter &
pm2 start /home/pi/scripts/*
Xephyr -br -ac -noreset -screen 1920x540+0+540 :1 &
Xephyr -br -ac -noreset -screen 960x540+0+0 :2 &
Xephyr -br -ac -noreset -screen 960x540+960+0 :3
~/.xinitrc

Within the scripts directory there are three files, one for each camera and one for CueView, these are ran automatically by pm2, and restarted if they fail;

#!/usr/bin/bash
DISPLAY=:2 cvlc --live-caching 10 --clock-synchro 0 --clock-jitter 0 --network-caching 10 --fullscreen 'rtsp://10.0.0.51/Streaming/Channels/101'
~/scripts/cam1_stage_colour.sh
#!/usr/bin/bash
DISPLAY=:3 cvlc --live-caching 10 --clock-synchro 0 --clock-jitter 0 --network-caching 10 --fullscreen 'rtsp://10.0.0.51/Streaming/Channels/101'
~/scripts/cam1_stage_ir.shc
#!/bin/bash
DISPLAY=:1 /home/pi/cueview
~/scripts/cue_view.sh

Customising Cue View

Configuring CueView is probably easiest with a keyboard and mouse attached, but we didn't have one. Instead, we used the existing settings from our Mac running Cue View and simply copied them to the Local Storage on the pi;

scp -r Library/Application\ Support/Cue\ View/Local\ Storage pi@10.0.0.200:~/.config/Cue\ View/Local\ Storage

In order to maximise the display space, we made a few minor customisations to Cue View (it's just an Electron web-based app, so it's extensively customisable via CSS)

The small changes we made are shown below, this removes the device list and hilight (as you can't edit it anyway) so provides a clean, matching appearance for both Eos and QLab.

#main {
  box-sizing: border-box;
  display: grid;
  width: 100%;
  height: 100vh;
/*  grid-template-columns: 270px 1fr; */
  grid-template-columns: auto;
}

#device-list-col {
  display: none;
}

.active-device-outline {
}
Changes in Cue-View/src/assets/css/index.css

And also, to the window itself in main.js to optimise it for the 1920x540 resolution

const windowWin = {
  width: 1920,
  height: 540,
  backgroundColor: '#000000',
  fullscreen: true,
  webPreferences: {
    contextIsolation: false,
    nodeIntegration: true,
    preload: path.join(__dirname, 'preload.js'),
  },
};
Changes in Cue-View/main.js

This is obviously tailored to our particular venue, but the technique could be adapted to anything and even more tiles (or a simple split screen)