Computer Science for Musicians

Roland Gurt, a musician and regular reader here, recently asked whether I could explain some of the computer science terminology that keeps appearing in these posts – terms like functional programming, immutability, and transducers – in layman's terms, and preferably from a musical point of view.

I was genuinely glad to be asked.

At this stage of Ooloi, nothing has yet been drawn on the screen. What has been happening is work on problems that sit underneath notation, problems that have been considered 'mostly solvable' at best since the 1980s. The deterministic accidental system I recently wrote about is one such problem. It looks abstract because it has to be. It deals with musical meaning before anything becomes visible.

This post is an attempt to explain why these terms keep appearing, and what they actually refer to, without turning this into a programming tutorial. It's written for musicians who are curious, not for programmers who already know the vocabulary.

Starting Without Baggage

​One reason Ooloi can attempt this at all is that it's a new system.

Most notation programs in use today have roots in techniques from the 1980s and 1990s. Internally, they tend to look surprisingly similar. They represent music in roughly the same way and rely on the same architectural assumptions: object-oriented design, mutable state, and large codebases written in C or C++.

Once a system has grown for decades on top of those assumptions, it becomes extraordinarily difficult to rethink its foundations without breaking everything at once. We saw Finale collapse in 2024 for precisely this reason.

There have been only two real departures from that lineage. One was Igor Engraver in the 1990s. The other was Dorico from 2016. Dorico has much in common with Igor Engraver in terms of musical data representation, and it made important advances. But even Dorico still rests on the technological assumptions of that era: object-oriented design, mutable state, and C++ at its core.

Ooloi puts all its money on a different assumption, namely that those older techniques fundamentally are architecturally inadequate for the problem of music notation as we now understand it. That inadequacy has consequences for users: accidentals behaving oddly, freezes and delays, limited scalability, no real collaboration, and poor use of modern multi-core machines.

​To address these problems, Ooloi uses an entirely different set of techniques.

A Genuinely Hard Problem Domain

​It also needs to be said very clearly that music notation, from a computer science perspective, is an extremely hard problem.

It's not 'a word processor for music'. That analogy has done lasting harm.

Music notation sits in the same general complexity class as compiler construction, symbolic mathematics systems, or advanced typesetting engines. It combines several difficult aspects at once: hierarchical structure, temporal meaning, long-range context, simultaneous layers, and a visual representation that's not a straightforward reflection of the underlying data.

A compiler reads a stream of symbols, builds meaning from context, enforces consistency rules, and produces deterministic output. Music notation does all of that, and then adds engraving conventions, historical practice, performer expectations, and visual clarity on top.

If you approach this domain with tools designed for relatively static documents or interactive graphics, you end up fighting the problem instead of modelling it. The result is systems that work impressively most of the time, but fail in edge cases, which in music aren't rare.

Determinism as the Musical North Star

​Before any technical terminology enters the picture, there's a simple musical requirement.

If you engrave the same piece twice, you should get the same result twice.

Not roughly the same. Not 'close enough'. The same.

Most notation software quietly gives up on this requirement. Instead, they rely on rules of thumb: 'this usually works', 'this is how engravers tend to want it', 'clean this up manually if it looks odd'. Musicians have learned to live with that because, for a long time, there was no alternative.

From a musical point of view, this is deeply unsatisfactory. It means the system doesn't really know what it's doing. When things get complicated, it starts guessing. And once guessing enters the picture, everything downstream becomes fragile.

Determinism simply means that given the same musical input, the system makes the same musical decisions every time.

---

Immutability: Trusting what has Already Happened

​Imagine packing a suitcase before a trip. You put clothes, toothpaste, shoes inside. Once the suitcase is closed and checked in, you make decisions based on what you packed. You don't buy extra clothes at the airport because you trust they're already there.

Now imagine that, while the suitcase is in transit, someone silently changes its contents. In a trivial case this is merely annoying. In a serious system – air-traffic control, medical records, nuclear command – it's catastrophic: people might die.

To reason about anything, you must be able to trust the past.

In computer science, immutability means this: once a thing has been created, it never changes. If you need a slightly different version, you don't alter the original. You create a new one. The old one remains exactly as it was.

This sounds wasteful until you realise that modern systems can do this efficiently by sharing structure internally. This is where a bit of Harry Potter magic comes in. If someone changes one shirt, they get a new suitcase with just that one shirt changed, while you still have your original suitcase, untouched and with the original shirt still inside.

In music notation this matters because the domain is full of remembered context. Accidentals depend on what happened earlier. Key signatures establish expectations. Voices interact. If earlier musical facts can silently change while later decisions depend on them, determinism collapses.

---

Functional Programming: same Input, same Result

​Most people already understand from school what a function is.

If x is 100, the result is always 101. Not sometimes. Always.

That property is determinism.

Now imagine that x is not a number but a suitcase. If the function's result depends on what is inside the suitcase, you must be absolutely certain that the contents haven't changed since last time. And for this, the suitcase needs to be one of our magical suitcases. Otherwise, calling the same function twice with what looks like 'the same input' might silently produce different results. The consequences range from a missing accidental to obliterating Tokyo.

Functional programming is simply the discipline of insisting on this property at scale. Functions don't reach out and change things behind your back. They don't depend on hidden mutable state. They take inputs and return results without any such surprises.

In Ooloi this matters because musical decisions must be reproducible. If accidental decisions or tie behaviour depend on invisible state changes, the system cannot be fully trusted, even if it usually looks right.

The Score as a Semantic Stream

A central idea in Ooloi is to treat the score as something that flows.

Music is read from left to right. Context accumulates. Decisions depend on what has already passed. Accidentals are remembered and later forgotten. Grace notes steal time from what they follow. Tuplets locally distort time.

This is not a static tree that you occasionally inspect. It's musical meaning - semantics - unfolding over time.

Once you accept that, you need a way to traverse this stream efficiently without constantly rebuilding lists or retracing paths.

​And this brings us to transducers.

---

 Transducers: Separating the Route from the Work (in the Jail of Recursive Descent)

​Imagine a high-security prison complex with multiple buildings, floors, and endless cells. Every day, a warden must traverse the entire structure to take stock of what's inside. And he must do it in the same order each day, just as the notes in a piece must be played in the same order each time.

Most of the warden's effort goes into navigation: remembering routes, tracking where he's been, writing lists just to keep his place. He does this over and over again, every day.

A transducer is like giving the warden Ariadne's thread. But again, there's magic involved: the thread weaves from cell to cell of its own accord. The route through the maze is fixed and reliable. Navigation stops being the problem. 

Better still, the warden doesn't even have to walk, thanks to more magic: the thread acts like a firehose and sends back all the information to the origin. The warden can sit in his office while the traversal happens and receive a continuous stream of information about what's found along the way. He can devote his entire attention to the meaning of the data, not how to walk the prison complex.

The crucial point is that traversal and processing are separated. The route is handled once. The real work happens as data flows past, without intermediate lists or repeated navigation.

In Ooloi, transducers allow musical meaning to be processed in exactly this way. The system doesn't build a large structure and then analyse it afterwards. It reacts to musical facts as they appear, deterministically and efficiently.

This is what a transducer is. Then there's even more wizardry involved in that several transducers can be stacked on each other to perform even more abstract operations. The path has been abstracted away, the distractions are gone, and the flow of  meaningful musical data is all that matters.

---

Vocabulary

​These terms aren't ideology, and they're not badges of virtue. They're simply the most precise language I've found for describing how musical meaning behaves when you try to handle it rigorously.

The music comes first. The vocabulary follows.