​A few weeks ago I wrote a post explaining computer science terminology to musicians. This is the inverse: an explanation of music notation for programmers who assume the domain is simpler than it is.

That assumption is common. It's also expensive. Most notation software has been written by very competent engineers who underestimated the problem. The result is systems that work impressively until they don't – at which point they fail in ways that seem arbitrary to users but are, in fact, architectural.

This post explains why.

​Here is a concrete example of why music notation is harder than it looks.

Question: Does this F need a sharp sign?

Answer: It depends on:

1. The key signature (established possibly pages earlier)
2. What happened earlier in this measure in this voice
3. What happened earlier in this measure in other voices on the same staff
4. What happened earlier in this measure in other staves (in keyboard music, an F♯ in the left hand may affect an F in the right)
5. Whether there's a tie from the previous measure
6. Whether this is a grace note (different rules apply)
7. Publisher conventions (some always mark cautionary accidentals, some don't)
8. Historical period (18th-century conventions differ from 20th-century)

A naive algorithm checks each note against previous notes in the measure. This is O(n) per note, O(n^2) per measure. Fine for simple music.

Now add multiple voices. The F in the soprano might be affected by an F♯ in the alto, depending on conventions. You need to track alterations across voices. If voices cross staves (as in keyboard music), the interactions multiply.

Now add simultaneity. What happens when two voices sound the same pitch at the same instant but with different accidentals? Yet another edge case difficult to catch when imprisoned in the Jail of Recursive Descent.

Now add grace notes. A grace note at the beginning of a measure might be notated at the barline but sound at the end of the previous measure. Does its accidental affect the next measure? Does the next measure's key signature affect it?

The dependency graph for accidentals is not a simple sequence. It's a directed acyclic graph with edges determined by temporal position, voice membership, staff assignment, and notational category. Correct handling requires topological sorting with domain-specific edge semantics.

Most notation software handles this with heuristics: rules-of-thumb that cover common cases and fail on uncommon ones. The failures aren't bugs in the usual sense. They're consequences of architectural decisions made decades ago when the problem was less well understood.

Ooloi handles this through what I call the 'timewalker' – a transducer that processes musical events in semantic order (not storage order) allowing full temporal context accumulation. The accidental algorithm becomes stateless over its input stream: given the same sequence of musical facts, it produces the same decisions. Deterministically. Every time.

The complexity is still O(n · v) for n events and v voices, but the constant factor drops dramatically because traversal and processing are separated. The transducer handles navigation; the algorithm handles meaning.

​Here is where most notation software fails silently.

A modern computer has multiple cores. Users expect responsiveness: type a note, see it appear immediately. But notation isn't like a word processor where inserting a character affects only nearby layout. Changing one note can alter accidentals throughout a measure, reflow an entire system, or invalidate cached engraving calculations across pages.

The traditional approach is to serialise everything. One thread handles all mutations. The UI blocks or queues. This is why notation software freezes when you paste a large passage, or why collaborative editing remains essentially unsolved in this domain.

The problem deepens when you consider what 'correct' means during an edit. If a user changes an F♮ to an F♯ in measure 4, the accidental state of measure 5 depends on this change. But if the rendering thread is currently drawing measure 5, what does it see? The old state? The new state? Some inconsistent mixture?

Mutable state with locks doesn't solve this; it creates a new category of bugs. Deadlocks. Race conditions. Heisenbugs that appear only under specific timing. A very difficult work environment indeed, and one where diminishing returns becomes a real impeding factor.

The functional approach is different. If musical data is immutable, the question dissolves. The rendering thread has a consistent snapshot – always. The editing thread produces a new snapshot. There's no moment of inconsistency because there's no mutation.

This is what Software Transactional Memory provides in Clojure. Transactions compose. Reads are always consistent. Writes are atomic. The system guarantees that no thread ever sees a half-updated score.

The performance implications are substantial. Ooloi's STM handles heavy contention without the coordination overhead that serialised systems pay constantly. The bottleneck shifts from synchronisation to actual work.

Real-time collaboration becomes architecturally possible. Two users editing the same passage don't corrupt each other's state; they produce alternative futures that the system can merge or present as conflicts. This isn't a feature bolted on afterwards. It's a consequence of representing music correctly from the start.

​Programmers sometimes assume that once you have the musical data, displaying it is straightforward. Calculate positions, draw glyphs, done.

This underestimates the problem by roughly an order of magnitude.

Consider accidental placement in a dense chord. Multiple accidentals must avoid colliding with each other, with noteheads, with stems, with ledger lines, and with accidentals in adjacent chords. The placement rules aren't arbitrary – they encode centuries of engraving practice optimised for readability.

This is a constraint satisfaction problem. In the general case, it's NP-hard. Real systems use heuristics, but the heuristics are subtle. Gould's Behind Bars – the standard reference on notation practice – devotes many pages to accidental stacking alone.

Now multiply by every other engraving decision: beam angles, stem lengths, tie curves, slur routing, dynamic placement, tuplet brackets, ottava lines, system breaks, page breaks. Each interacts with the others. Change a stem length and the beam angle needs adjustment; beam ends need to follow sit-straddle-hang rules and might both move. Change a beam angle and adjacent voices may collide.

LilyPond's engraving quality comes precisely from treating this as a serious optimisation problem. Its page-breaking algorithm runs a variant of the Knuth-Plass line-breaking algorithm (developed for TeX). Its spacing uses spring-based constraint systems. The 'simple' rendering layer contains some of the most sophisticated code in the system.

Interactive notation software faces an additional challenge: these calculations must be fast enough for real-time editing. You can't spend ten seconds optimising layout every time the user adds a note. The tension between quality and responsiveness has driven much of the architectural evolution in this field.

​A programmer encountering music notation for the first time will find countless apparent inconsistencies. Surely these could be rationalised?

No. Or rather: not without destroying information.

A fermata on a note means 'sustain this note'. A fermata on a barline means 'pause here'. A fermata on a rest means something slightly different again. These distinctions emerged from practice. Composers use them. Performers understand them. A system that normalises them into a single 'fermata event' loses musical meaning.

Grace notes in Bach are performed differently than grace notes in Chopin. The notation looks similar. The performance practice differs. A system that treats all grace notes identically will produce correct output that performers find misleading.

Clefs change meaning by context. A C-clef on the third line is an alto clef; on the fourth line, a tenor clef. Same symbol, different staff position, different meaning. This isn't legacy cruft – orchestral scores routinely use multiple C-clef positions because different instruments read different clefs.

Mensural notation (pre-1600) has entirely different rules. The same notehead shapes mean different things. Accidentals follow different conventions. Barlines serve different purposes. A truly comprehensive notation system must handle this or explicitly disclaim it.

The temptation to clean this up, to impose regularity, to treat historical conventions as technical debt – this temptation must be resisted. These conventions encode musical knowledge. Destroying them in the name of consistency destroys the knowledge.

​All of this serves a purpose that has nothing to do with computers.

Notation exists to communicate with humans. Specifically: performers who bring interpretation, physical constraints, and centuries of inherited practice to their reading.

This isn't sentimental. It has engineering consequences.

A page turn in the wrong place forces a pianist to stop playing or memorise a passage. This is a functional failure, not an aesthetic preference. The page-breaking algorithm must allow this to be modelled.

Awkward beam groupings obscure metric structure. The performer reads beats through beam patterns. Wrong beaming means wrong emphasis. The beaming algorithm must model this based on the currnent time signature.

Unclear voice leading forces performers to decode the texture before they can interpret it. The system must make voices visually distinct in ways that match musical distinctness.

Engraving choices that are mathematically equivalent may not be performatively equivalent. Two layouts might use the same space and avoid all collisions, but one reads naturally and the other requires active deciphering. The difference matters.

This is why notation is not a solved problem. The specification is 'communicate musical meaning to human performers'. That's not a format spec. It's a design constraint that touches every decision in the system.

Music notation looks like a data format problem. It is actually a meaning representation problem with a millennium of accumulated context.

The systems that fail – and most fail in some way – do so because they treat notation as something to be processed rather than something to be understood. They model the symbols without modelling what the symbols mean.

The systems that succeed take the domain seriously. They represent time exactly. They handle multiple hierarchies without forcing false containment. They process context correctly even when context is non-local. They treat engraving as a real problem, not a rendering detail. They preserve historical conventions because those conventions carry meaning.

This is why Ooloi's architecture looks the way it does. Rational arithmetic isn't ideology; it's the only way to represent tuplets exactly. Immutability isn't fashion; it's the only way to guarantee that accidental decisions are deterministic. Transducers aren't showing off; they're the cleanest and most efficient way to process a semantic stream with accumulated context. STM isn't over-engineering; it's the only way to achieve both correctness and responsiveness without sacrificing either.

The domain dictates the tools. Not the reverse.

Standard practice in many house styles is to show a courtesy accidental at the start of a new system when a tied note continues across a system break. In traditional notation workflows, this is handled manually: the engraver adds or forces the accidental after layout.

That manual step has consequences. A courtesy accidental has width. Adding it can push spacing past a threshold, move a system break, or reflow measures. A small local correction can trigger a cascade elsewhere, sending the engraver back to the same passage again. This is not a matter of care or skill. It is a side effect of heuristic layout combined with post-hoc correction.

Ooloi takes a different path.

Courtesy accidentals that exist because of a system or page break are derived, not edited. Ooloi has user settings to control preferred behaviour – such as whether these accidentals appear at all system breaks, page breaks only, or not at all. The required space is known before layout begins. System and page breaks are explicit decisions, and the distribution pass incorporates these accidentals exactly once.

Edit the score and the layout is recomputed.
Change a preference and the layout is recomputed.

There is no iterative correction loop, no heuristic adjustment, and no manual cleanup phase. Layout-dependent notation is a deterministic consequence of the score, its breaks, and the engraver’s stated preferences.

Two weeks ago, the remembered alterations algorithm proved that accidental rendering could be solved deterministically. I wrote about needing to breathe, to get my head around it.

Today, I formally specified measure distribution as ADR-0037. The Knuth-Plass algorithm – the same dynamic programming approach TeX uses for paragraph breaking – applies directly to distributing measures across systems. Not through cleverness, but because Ooloi's five-stage rendering pipeline decouples concerns that traditional architectures leave coupled. By the time the distribution algorithm runs, collision detection and vertical coordination are already resolved. What remains is a one-dimensional sequence with scalar preferences. Textbook problem. Textbook solution.

The algorithm itself is not news. Knuth-Plass has existed since 1981.

The news is that this is the second time.

Two problems the industry treats as inherently heuristic – requiring manual correction, special cases, user-facing options to tune approximations – collapsed into straightforward algorithms. Same architectural properties both times: immutable data, rational arithmetic, explicit stage boundaries, semantic determinism before layout.

Once might be coincidence. Twice suggests the architecture itself is doing something.

For engravers, if this holds: no accidental weirdness. No measure distribution cleanup. No jitter when editing – changing bar 47 won't mysteriously reflow bar 12. Layouts that are globally optimal, not locally adjusted. Proportional spacing preserved by construction. Adjustments for taste, not necessity.

I keep writing 'if this holds' because the proof is mathematical, not yet empirical. The algorithm is sound; the question is whether real scores – Gesualdo madrigals through Berg's Orchesterstücke or Ligeti's Requiem – expose edge cases the staged pipeline doesn't fully decouple. The remembered alterations work is tested. Measure distribution needs equivalent validation.

But the pattern emerging is harder to dismiss than any single result. If two 'impossible' problems turn out to be straightforwardly solvable, how many others?

I don't know yet. That's the honest answer.

Roland Gurt's comment last week – about spacing instability in the programs he uses, where editing one element mysteriously reflows unrelated staves on following pages – started me thinking seriously about this problem. Thanks, Roland.

Happy New Year, everyone.

​I'm re-reading Gardner Read's Music Notation from 1974. I bought my copy in 1977, which makes me 16 at the time – old enough to take it seriously, young enough to believe comprehensive understanding was achievable through diligent study. Later, this book would influence Igor Engraver's formatting decisions, though not always in ways I'd care to defend today.

What strikes me now is what Read doesn't cover. There's nothing about ledger line thicknesses, actual distances in spaces between noteheads and accidentals, sit-straddle-hang rules, slur curvatures, or tie formatting. None of the engraver-level detail that Elaine Gould's Behind Bars (2011) and Ted Ross's The Art of Music Engraving & Processing (1970, but I didn't discover it until much later) document so comprehensively. Read gives you musical orthography – what symbols mean and when to use them – but not typographical execution.

​When Magnus Johansson published examples of Igor's output on NOTATIO recently, I experienced that particular species of discomfort that comes from seeing your 25-year-old work through 2025 eyes. The ledger line thicknesses were wrong. The beam slants were inconsistent. We clearly knew nothing about sit-straddle-hang.

So what made Igor well-received? Not typographical perfection, that's certain.

First, integrated parts. Only Composer's Mosaic had them at the time, and Igor had them long before Finale or Sibelius. This alone solved a workflow problem that cost professional copyists days of manual labour.

Second, the user experience didn't fight the music. After spending years with Finale on The Maids – full score, parts, piano reduction – I ended up hating Finale. I've called it 'as user-friendly as a cactus' more than once. Creating something that didn't actively work against the creative process was evidently a sufficient innovation.

Third, note entry was fast and powerful. The modal Flow Mode interface that would later vanish completely from notation software for 23 years gave professional users substantial note entry and editing speed improvements. When you're saving many hours per score, you'll forgive a few ledger lines being slightly too thin – and there was a setting for that anyway.

Fourth, we had stellar MIDI playback and a semantic model that made things consistent rather than a collection of rules-of-thumb. That alone provided predictability. And everything could be adjusted – the absence of automatic sit-straddle-hang rules just meant more manual interventions.

The landscape in 1996 made these trade-offs reasonable. The streamlined experience outweighed what we today immediately see was missing.

​2025 is not 1996.

The leading programs have improved considerably since 1996. They're genuinely competent at beam placement and formatting – not flawless, but competent enough that egregious errors are rare.

A new program entering this landscape must get the foundations correct from day one. Beam placement, slurs, ties, accidental positioning – these must be flawless, not 'good enough to ship'. The field has progressed, and users' baseline expectations have risen accordingly.

This is as it should be. But there's something deeper that hasn't been solved.

Here's what I've stated repeatedly: Ooloi is not about 'disruption' or market share. The entire motivation is to escape what commercialism leads to and create something modern, scalable, and architecturally correct from the ground up. Why? Because music notation is an extremely messy and difficult field of computation, and it requires correctness to address its long-standing problems of scalability and accuracy.

This starts with internal representation.

The old programs – and many modern ones still in broad use – were all based on a paradigm inherited from MIDI. MIDI was the standard for pitch representation at the time, and all notation software needed MIDI output for playback anyway. This meant pitches were MIDI numbers (0-127) with attachments indicating whether they were sharp or flat. Figuring out musical context – for instance, to determine what accidentals to draw – had to be derived from something with no connection to musical structure whatsoever. It had to be inferred from context each time.
​
That's at the root of the problems programs still have with accidentals. The internal representation is designed around the presentation – the visual aspect – not around the meaning, the semantics, of the music.

And of course, MIDI has no concept of microtonality, which is why notation programs struggle with microtonal entry, presentation, and playback.

Furthermore, for duration, these early programs based their rhythmic representation on a raster of 480 subdivisions – ticks – of a quarter note (TPQN: Ticks Per Quarter Note). A quarter note is 480 ticks long in some arbitrary tempo, an eighth is 240, and so forth. This is the equivalent of pixels in a JPEG, which means there's a limit to what the raster can represent.

The number 480 isn't evenly divisible by very many factors. This leads to all the problems we're still seeing in music notation programs. Various kinds of duct tape – rules of thumb, arbitrary rounding, tolerance spans – have to be used. When tuplets are nested, the approximation errors compound. We're still seeing the effects of this unfortunate MIDI heritage in 2025.

A MIDI-derived representation centred on presentation – the visual aspect – will always have difficulty interpreting what the music means. That interpretive layer is essential for presenting it correctly and consistently.

For that, you need a semantic model, which turns this on its head. The representation is 'musically correct' and detached from its presentation. Once this is in place, you can make informed decisions instead of relying on rounding and rules-of-thumb. It also makes things like playback trivial, which in MIDI-based systems is paradoxically complex.
​

​Igor Engraver was, I believe, one of the first programs – possibly the very first – to use a fully semantic internal model. It was also the first to model the real world by using Musicians playing Instruments, which allowed new and powerful abstractions.

It's interesting that Dorico also has this arrangement, though they call their Musicians 'Players' – but it's the same thing. I have no idea whether Daniel Spreadbury was inspired by Igor here, but it's not unlikely. On the other hand, introducing Musicians/Players into the representational hierarchy is a logical choice once you commit to semantic modelling.

I'm not certain Dorico has a fully semantic model, though it's closer than any other program I know of. LilyPond doesn't, despite its sophisticated batch nature. One telling diagnostic: look at how they handle remembered accidentals for grace notes, and how they treat them rhythmically. Another: how durations are represented. If they're floating-point numbers, they're approximations. For true accuracy in all situations, you need rational numbers – infinite precision, always correct. Anything else eventually leads to problems.

If a program has problems with edge cases or behaves inconsistently when dragging things cross-staff, check how it represents pitch and duration. If floating-point is involved, or rasters of ticks (480 or otherwise), the representation isn't semantic. The program might still handle 95% of hairy accidental placements competently. But when it starts having problems with tied notes across key changes or grace notes at measure starts, you know rules-of-thumb are involved – which means results can never be fully deterministic.

Ooloi is fully semantic with the explicit intention of making results fully deterministic.

This might not matter if you're satisfied with what capable commercial programs achieve today. That's legitimate – they handle about 95% of cases well. But if you depend on the remaining 5%, or if you spend your days as an engraver adjusting those 5% repeatedly, then you understand what I mean by deterministic results saving considerable time.

Now, on to Gould and Ross – books that weren't available when Igor was created. We'd inevitably have implemented their specifications had we had time. But as you know, I was ousted from my own company by venture capital pop zombies before we could. They thought guitar tablature was more important than correct engraver-level beaming.

This time, there will be no guitar tablature at the expense of correct beaming and orthography. All things in their proper order. Lead sheets are kid's stuff, comparatively speaking, and will be added later as plugins.

​Each stage is pure transformation. Grace notes are repositioned to exact temporal locations based on tempo-dependent duration (85ms default, compressed on collision). Simultaneities group by rhythmic position. Conflicts detect same-letter different-accidentals at the same moment. The reducer threads remembered state through the stream, accumulating decisions.

This pattern will handle dynamics, articulations, phrase marks: any notation requiring temporal context. The abstraction scales because the foundations were right to begin with.

​The algorithm produces semantic decisions about accidental requirements, independent of layout. These decisions are deterministic: same music, same decisions, always. They're layout-independent: work identically across all visual representations. They're configurable: house style settings modify behaviour without code changes. They're correct: edge cases handled through the same mechanism as common cases.

But here's what matters: I didn't design these four systems to work together. I designed each to solve its own problem correctly. The alignment emerged because correct solutions in related domains tend to compose naturally.

This is evidence. Either the domain model reflects musical reality accurately, or I've successfully imposed coherent structure on chaos. Those are different conclusions with different implications, but both suggest the foundations can carry what comes next.

​Why now? Why remembered alterations before any visualisation exists?

Because I needed to know whether the foundations were actually complete. Pitch, rhythm, key signatures, temporal traversal: individually validated, but never tested as a system. Remembered alterations forced that test. If they didn't align naturally, I'd have learned something important about what was missing.

They aligned. Beautifully. With no compromises in existing architecture, no special cases, no friction. Four systems built independently composed into a solution more elegant than any I'd planned.

That's conceptual closure. That's knowing the foundations are right before proceeding to build on them. That's why this work happened now, before technical necessity demanded it.

The next phases (windowing, rendering, note entry) will build on these same primitives. But now I know they're sound. Not because I believe they should be, but because I've seen them work together when they had no reason to unless the underlying model was correct.

The window opens soon. But first, this needed to be right. Now I know that when notes appear on screen, there will be no special cases left to fix, no rules-of-thumb to implement. Accidentals are now correct regardless of staff, voice, cross-staff, or cross-measure situation or house rule preferences.

​Es ist alles eins, as Marie sings in Wozzeck. But in a good way.

​Bärenreiter, Durand, Peters, Schott, Universal Edition. Publishers whose engravers spent ten years learning how to disappear behind their craft.

The copper-plate aesthetic: bold, confident, generous. Staff lines weighty enough to guide the eye, noteheads round enough to feel sung, stems drawn with conviction.

Modern digital engraving forgot this. It grew thin, bloodless — optimised for screens instead of for musicians.

The lineage is clear, and the standard unchanging: those 1920s scores, those shortened ledger lines, that unspoken discipline that still knows how to sing.

We all worship at that shrine.