Ringing Room Under the Hood

This is the first in a series of posts discussing the technical decisions that went into creating Ringing Room, the first web platform for distributed English change-ringing. This first post gives some background on change-ringing; my aim is to give just enough background to enable non-ringers to follow the discussion that follows. For a more complete introduction to change-ringing, see here or here. The other posts in the series are:

1. Ringing Room Under the Hood (this post)
2. Communications
3. Towers
4. (coming soon!)

Ringing Room is the first web platform for distributed bell-ringing. I developed it together with my partner Bryn Reinstadler starting in March of 2020; since then, it has become the de facto standard for online change-ringing, with several thousand daily visitors. It’s been a wild ride getting here — RR was my first major web app project, and saw high usage within the first week after launch and ever thereafter; we were definitely building the proverbial plane while flying it. The goal of this series of posts is to catalog some of the decisions we made along the way and to discuss what I learned from the process.

What is change-ringing, anyway?

I have a few favorite ways of describing change-ringing to non-ringers. When I’m talking to software folks, I like to call it traditional algorithmic music. When I’m talking to musicians, I like to call it folk serialism. And for everybody, I like to say that it’s a mathematical-musical team sport. Change-ringing is an ancient art going back to at least the 1600s; it involves ringing large church bells¹ in algorithmically-generated weaving patterns to create a never-repeating string of permutations. A full introduction to the art-form is beyond the scope of this series — see the links I put at the top if you want to know more — but there are a few key features of ringing that will be important to understand the discussion to follow.

Here’s an example of some change-ringing illustrating the basic points I’m going to mention below.

Ringing is done by bands of ringers working together. In general, each ringer is in charge of 1 bell; when ringing handbells (rather than tower bells), ringers generally take 1 bell in each hand instead. The ropes or handbells are generally arranged in a circle so all the ringers can see one another during ringing. Ringing consists of a sequence of rows, where each row involves each bell ringing exactly once; within a row the rhythm is constant, with (optimally) an even gap between each individual bell ringing.² When you’re in the ringing chamber, you can’t see the bell itself, but only the rope. The ropes alternate between two positions: One where most of the rope is in the ringing chamber, and one where most of the rope has been pulled up through the ceiling. We thus say that a bell has two distinct strokes; this parity is an important cue for keeping your place in the ringing.³

During a piece of ringing, there’s generally one person playing the role of conductor. Their job is to put in calls (things like “start ringing now” or “change pattern here”) at particular times, and also generally to look after the ringing.

Finally, a word about the social organization of ringing. Most ringing takes place in semi-regular practices, where ringers take turns at ringing a variety of shorter pieces. But there are also longer “performances” in form of quarter-peals (comprising at least 1250 rows, or around 45 minutes) and peals (comprising at least 5000 rows, or around 3 hours).

The Latency Problem

Anyone who’s ever used videoconferencing knows that latency is an inevitable problem for any kind of real-time online activity. It’s always going to take some amount of time for information to travel between two computers. This, in the general case, means that distributed music is not possible: If you’re trying to have two musicians play together online, both of them will perceive the other one has being constantly slightly late. And that’s assuming that the latency is constant, which it never is! So given this, how is ringing online even possible? There are two features of change-ringing that make this possible:

1. No two bells ever need to ring simultaneously. This means that, in the worst case, bell 2 can always wait to hear Bell 1 before proceeding.
2. The rhythm never deliberately varies. In other music, the difference between “long short” and “short short” is significant — those two sequences correspond to different musical intentions. But in ringing, there is only ever “short short” — so if there’s a delay in transmission that turns it into “long short”, the receiver still knows what the intention was and can respond accordingly.

The Design Brief

Given the above, we can come up with a set of minimal design goals for an online ringing platform:

1. The platform should have “rooms” so that multiple practices or performances can take place simultaneously without interfering with each other.
2. Within each room, there should be visual representations of an appropriate number of bells that conveys what which of the two possible stroke the bell will ring next.
3. There should be some facility for determining which ringer is assigned to ring which bell(s).
4. Triggering a bell (via click, keypress, or some other method) causes the state of that bell to swap and a sound to play for all ringers currently connected to that room.
5. Finally (and somewhat optionally) some provision should be made for the conductor to make the necessary calls during ringing.⁴

These are the goals I set out to meet when I first designed Ringing Room. Along the way, many other features were added in response to user requests — text-chat, “bookmarking” of towers, restrictions on who can administrate individual rooms, and more.

In the next post in this series, I’ll discuss how Ringing Room uses Websockets to enable real-time ringing, and what tools I use on the back-end to facilitate this.