In June I published a road map and claimed the list was plumbing, every line of it. It was. Networking, certificates, session persistence, collaboration state, window geometry: nothing on that list would ever appear on a page, and the whole argument for doing it then was that none of it would be sharing the desk when the page finally arrived.

That list is nearly spent, and what replaces it is a different kind of work:

Everything about a piece except the music itself can now be manipulated from the interface.

That reads like a summary. It's actually a precise statement, and it names a boundary the architecture drew long before this summer. Changes to the things that contain the music – musicians, instruments, staves, layouts, and a piece's own settings – announce themselves structurally the instant they happen, on every connected client. Changes to the music itself defer to the formatting pipeline, which is asynchronous and which doesn't yet exist. One side of that line is now complete, all the way up to the interface. The other is a routing-table entry with no producer and no consumer.

The summer went into the first side. Pieces open and save and close and reopen where you left them. Musicians and instruments are created, numbered, renamed, cloned, reordered and deleted by gesture, with the numbering falling out of the gesture rather than out of a dialog. Layouts assemble into scores and parts. A piece's settings live in a window of its own. A field refuses a value it cannot take, in the field you typed it into, in your own language. Every one of those acts is a single transaction, a single event, a single refetch, a single named step in the Edit menu, and the path is identical whether you are working alone or someone on another continent is working beside you.

The semantic model, in other words, finally has a surface. For two years it existed and could only be reached through tests. It can now be reached with a mouse.

Except for the music. Which is what the rest of the tickets are for:

The anxiety inverts here, which I hadn't quite anticipated.

Invisible work fails by remaining invisible. You solve something genuinely difficult and it vanishes into infrastructure, and the better you have done it the less anyone can see. I have written about that loneliness before.

Visible work fails by being looked at. Every judgement I make about a beam, a slur, a page, will be in front of musicians who have spent their lives reading engraved music and who will know immediately, and without being able to say why, whether it's right.

I'd rather have that problem. It is, after all, the one I set out to have.

Spring has finally arrived in Stockholm. I mention it only because there's a quality of north European light returning after winter that genuinely affects how work feels.

The past two weeks have been quiet on the Ooloi front, code-wise. I'm being onboarded into a large AWS project at work, where my decisions will eventually affect roughly five thousand developers, and onboarding at that scale absorbs a great deal of attention. What Ooloi work I've done has been architectural cleanup: the sort of small consolidations you make when the ground is about to be built on. Data field validation refactored to be entirely general, for instance. Not glamorous, but the kind of work that matters once it has disappeared from notice.

Ross also arrived this week. The 1987 third edition, posted from Melbourne in a padded envelope, in pristine condition, and now on the desk where it belongs.

Two weeks ago I wrote that I needed the book and couldn't buy it. The void was listening, as the coda noted. It is one thing to write that, and another to hold the consequences. The book is dense and beautifully exact where it counts. It's also, in places, at odds with itself, which is the honest record of any craft this old. The beaming section alone runs to fifty pages and doesn't entirely agree across them; the accidental positioning sections give horizontal spacings down to fractions of a stave space. Exactly what I'd hoped for. Translating it into data and code will be a pleasure.

What strikes me paging through is how much of the material I already know in some sense. Musicians absorb this kind of thing through a lifetime of reading and writing scores. The interest is not the content as content; it's the formalisation. Ross surfaces principles that intuition alone never quite articulates. He's rigorous about things most musicians never have to put into words, and that's where the real value sits. It's also what makes the book usable as a specification rather than as commentary.

The road ahead, briefly. The Piece Window comes first, multi-user collaboration aware from the start, built on the patterns the Instrument Library established. After that: frontend session persistence so windows reappear where you left them; the Piece Preferences window (also collaboration aware); clock skew compensation for reliable distributed undo and redo; and the full multi-mode client work, with Google-Docs-style permission management for connecting peers. That last item closes a chapter. Once it's done, I won't have to think about multi-user logic again. It'll simply be there.

Then plugins for all JVM languages, a first version of MusicXML import and export, and Skia/Skija with GPU acceleration. The last of those is when SMuFL fonts can finally be drawn on the page.

After which the rendering pipeline proper begins. The first stage draws everything except the music: page numbers, titles, headers, footers, staves, system barlines, braces, brackets, instrument names. Crucially, it's done through the plugin system itself, in Clojure plugins. If you don't like the choices, you can replace them, in whatever JVM language suits. I'm not sure it'll ever be necessary, but it can be done if so desired.

Then the interesting material: noteheads, horizontal spacing, flags, augmentation dots, multi-voice collision resolution, accidental clustering, unisons. Everything that isn't a spanner. The solver gets the supposedly easy work first.

Spanners last: beams, ties, slurs, hairpins, glissandi, lyrics, pedalling, 8vas. Where Magnus's question about hovering secondary beams will finally have somewhere proper to live.

But first: piece windows. Expect GIFs/videos soon!​

Elaine Gould's Behind Bars is here. Ted Ross's The Art of Music Engraving and Processing isn't, because there's nowhere to order it from. The print edition has been dead for decades. Hansen Books no longer functions in any meaningful commercial sense. Ted Ross himself is dead. Second-hand copies surface occasionally on AbeBooks or eBay, usually in poor condition, usually at absurd prices, usually spoken for within hours. The Internet Archive lends a scanned copy in twenty-four-hour slots. A Californian outfit called npc Imaging has sold a searchable CD-ROM edition since 2001, though whether it still runs on a modern operating system is an open question.

Which provokes the obvious one: do I still need Ross in 2026?

The temptation to answer no was real. The book was published fifty-six years ago. It describes a workflow of punches and gravers, of metal plates and photographic reproduction, none of which has survived the move to digital notation. Gould arrived forty-one years later, covers what publishers currently expect, and is in print.

But no. I need it.

Gould and Ross overlap, but their centres of gravity differ. Gould's focus is editorial: contemporary conventions, edge cases in modern repertoire, the negotiated practices that settle disputes between composer and copyist. Her domain is current, and her vocabulary includes extended techniques and the Ferneyhough generation's demands.

Ross's focus is geometric. Stem lengths with actual measurements. Beam angles. Optical spacing tables. Ledger line dimensions. The precise relationships between noteheads, stems, beams, and staff lines, specified with the exactitude of someone producing real plates. His specifications are tabular and implementable rather than descriptive. Ross becomes data in Ooloi; Gould has to be read and decided.

The invariance argument settles the age question. The five-line staff hasn't changed since 1970. A half note still looks the same. The geometric relationships Ross specifies have the same validity now as when he wrote them, because notation itself hasn't shifted underneath them. What dates in Ross is the production workflow, which I can skip entirely without losing anything I need.

LilyPond's spacing algorithms reference Ross directly. Gourlay's seminal paper on music spacing builds on him. The rendering pipeline I'm about to close – spanner geometry, optical adjustments, beam slope selection – sits more in Ross's territory than Gould's. Not consulting him would be working blind on problems he addressed head-on half a century ago.

So I need the book, and I can't buy it.

There's something grimly appropriate about this. Ross's book is the kind of reference work whose commercial half-life expires decades before its technical half-life even begins to decay. The market that would sustain a reprint is smaller than the importance of the content. LilyPond's continued citation of Ross is, in a sense, more preservation than any library has managed. The notation community keeps him alive by quoting him, not by reading him.

It's also, not incidentally, one of the reasons Ooloi's documentation looks the way it does. The normal fate of a specialist reference work is exactly what happened to Ross: the author dies, the publisher dissolves, the copies scatter, and fifty years later someone trying to do the work has to borrow the book in twenty-four-hour slots from a scanner in San Francisco.

None of which amounts to preservation.

And even if it did, neither book would be the final word. They don't fully agree with each other, because the engraving community and major publishers don't fully agree with each other. Ross, despite devoting some fifty pages to beaming, contradicts himself more than once within that span. This isn't a failing. Engraving is a living craft with regional traditions, house conventions, and genuine disagreements about what looks right; two books documenting it honestly will reflect those disagreements rather than paper them over.

Which means the rendering pipeline isn't a matter of looking up The Answer. It's a matter of taking positions in ongoing debates, and making the positions configurable wherever taste genuinely differs.

Ooloi's formatting is data-driven wherever it can be. Engraving rules live as editable values, not as switch statements buried in source code. Hard-coding them treats them as invariant when they aren't, and turns house styles into an act of patching rather than configuration. Which is how the real disputes get handled: Boosey & Hawkes flat beams against sloped ones, whether grace note beams separate from or share the main beam, whether a slanted beam group shears or rotates. Ooloi will rotate.

I'm looking forward to that.

Will Ooloi do French beaming?

Someone asked me this the other day.
​
Yes. Stave-line masking too. I built this once before, in 1996; there's no architectural reason Ooloi shouldn't have it. Both fall out of treating the beams, and the spaces between them, as something that sits on top of the stave rather than alongside it.