It’s the night that simultaneously excites and terrifies every single person in the room who’s entered, the night that can make or break your career as a radio presenter, and the night that provides the opportunity to have your talents judged by five industry professionals on the spot… in front of hundreds of fellow students. Our Events Officer Dan Wildman gives you the inside info on how Demo Factor works.

Whilst being the most unique show to take place during the National Student Radio Conference each year, Demo Factor is also the most technically challenging show in the SRA calendar to pull off. In this post, I’ll explain in more detail the technology behind Demo Factor and the magic required to make it work.

We can split this into a couple of sections – Stage, Show Control and Display.

There’s quite a bit happening on the stage, and only some of it is visible. As an overview of the hardware required, we have:

  • 5 x Red Buzzer inc. Microswitch
  • 1 x Gold Buzzer inc. Microswitch
  • 1 x Raspberry Pi
  • Loads x Hook-Up Wire

The Logic
The underlying logic here is quite simple – By connecting the common terminal on the microswitch to the ground pin on the Pi GPIO and the Push-To-Make terminal on the microswitch to a GPIO input, we make a basic circuit that completes when the switch is actuated (we do this by putting a big red button on top of it).

To summarise, pushing the button completes an electrical circuit – Read as “true” on the Pi when the circuit is completed and “false” when it is not.

The Code
By running a small Node.JS script on the Pi (N.B. – Node.JS is a Javascript runtime environment that allows an OS, in this case Raspbian, to run JS code outside of a web browser), we can run code each time the circuit state in one of the buttons changes. We have several bits of data at this stage – The new circuit state (true or false – “true” meaning that a button has been pressed, “false” meaning that it’s been released), and the number of the pin that has changed.

By connecting each buzzer with a different pin, and associating the pin number and the judge name, we can detect every time a judge has pressed a button and immediately know which judge has buzzed. Boom.

Communicating Changes
It’s all well and good being able to tell who’s pressed a buzzer and when, but we’ve still a bit of a problem to solve – We’re detecting the press, but it’s on the Pi; not the computer that’s running the show software.

I’ll explain more about the show software further in this post, but the way we communicate changes between the Raspberry Pi on the stage and the show software in the production gallery is with web technology called WebSockets.

In a nutshell, WebSockets are persistent, low-latency connection between multiple clients and a server that allow bidirectional communication via events, with the option of sending data. By placing a server between the show control software, the screen view, and the Pi, we can connect all parts to the same local network and send events between the set.

In this case, we can send an event via WebSockets to the server, which carries the judge’s name as data. In turn, this server can pass the event along to the screen view which processes the buzz (e.g. turning the correct cross red, playing the sound, and recording the judge as buzzed in the show state).

As an overview, pressing the button actuates the microswitch underneath, which is read by the Raspberry Pi that it’s attached to. This sends the name of the judge that pressed to a server which passes it to the screen view, which in turn processes the buzz into the various following actions.

Cleaning Up
Naturally, we make this as tidy as we can – The wires are grouped and hidden as best as possible, and the Pi is hidden underneath the table. This way the stage looks at neat as possible, but we’re still able to run all the necessary cables to connect five buttons to a GPIO board.

Show Control
The show control software is simply a webpage, operated from a laptop in the production gallery, that gives the operator control of the entire show. This is where demos are loaded into the system ready to be played.

The show control software also solves a pretty glaring problem from the stage section – We have five red buzzers which corresponds to a single buzzer per judge, but only one gold buzzer; how exactly do we know who’s pressed the gold buzzer?

Well, naturally, we can’t with technology. The show control software doubles as a failsafe system in case of button failure during the show, and allows the operator to trigger both a red and gold buzzer press at any given time. Whilst the red buzzers are only triggered when the stage buttons aren’t working correctly, the gold buzzers are triggered manually from the software whenever the gold button is pressed.

As before, the show control software communicates entirely with WebSockets to the same server that the Pi is connected to – Each action is a different event, and allows the screen view to behave different when various actions are triggered in the show control software.

Playing Demos
The primary purpose of the show control software is simply to load and play the various demos, using random numbers that are pulled out during the show.

Once entries close at 2pm on the show date, we download each demo and create a spreadsheet that assigns each submission a number, and associates this number with the appropriate name, station and twitter handle. We also rename each demo with a number, further associating the submission data with the entry and making the files anonymous until they’re played.

By reading the spreadsheet, the software can take a number input and pull the data for that specific entry. It can then send that data to the screen view, displaying the details but not playing the demo.

From there, once the demo is ready to be played, an event is sent to the server and on to the screen view containing the number of the demo to be played. The screen view then searches for a file with the path /demos/[number].mp3 , playing the demo associated with the details already showing on the screen.

The screen view is where the majority of the show logic actually happens. It’s responsible for keeping track of the current show state (e.g. buzzers pressed, demo details, audio, etc.), as well as for providing the screen that’s shown to the audience.

Show State
During Demo Factor, there’s a number of data points that need to be tracked at any given time. These include the judges, the current buzzer presses, whether all buzzers have been pressed, whether a gold buzzer has been pressed, who still has gold buzzers available, the demo, and the current elapsed time. Some of these are tracked throughout the entire show (e.g. remaining gold buzzers), whilst most are only tracked for the currently playing demo.

Once a new demo is loaded into the system, we reset the the majority of this data, essentially setting it all back to zero. This allows each demo to start on a clean slate, but keeps track of which gold buzzers have been used.
To make this easier, the web page that it displayed on the projector uses the Vue framework, making dynamic pages much easier to control and update.

Show Logic
After each buzzer press, a number of checks are carried out within the show software – Firstly, the correct judge is marked as buzzed. After this, the software checks to see whether every judge has buzzed. If the former check is true, the software will stop the demo and turn the screen red. If there are judges left that haven’t buzzed, however, then the demo will continue to play.

It will also check to make sure that a gold buzzer hasn’t been pressed for the current demo; if it has, then the buzz won’t be counted as the judges are locked out for the current session. If the buzz belongs to the judge who used a golden buzzer then the demo will be stopped.

With the gold buzzer, a different set of checks are carried out – Namely, these are making sure that a golden buzzer hasn’t already been used, and checking that the judge still has a gold buzzer left to use.

Finally, for each second that elapses of the demo, a check is carried out to ensure that the demo has not ran for longer than 1 minute and that a golden buzzer hasn’t been pressed. This check will be ignored if a gold buzzer has been used, but the demo will be stopped at the 1 minute mark in any other case.

So that’s the show state explained; but what about the videos? That’s the easy part.

We load all of our videos into the playout software QLab, which is connected to an ATEM Switcher allowing us to change between the two computers at will. Within QLab, we set up a specific sequence of videos inc. transitions to smoothly move between the various assets and holding loops.

By setting groups within QLab, we can trigger video sequences with key presses – For example, pressing “2“ would start the group responsible for the show countdown, fading out the previous video and fading in the countdown VT. At the end of the VT, it’ll fade out and back into the show loop, removing the harshness of jump-cuts from one to the next.

Being the most unique show to take place during the Conference, the entire hardware and software system is constructed and operated by the SRA specifically for Demo Factor.

If you have any questions about this, you’re welcome to email me or tweet me and I’ll do my best to explain!