The Machinery of Taste

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:

Where things stand

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:

Finishing what collaboration started

• #136 — Authenticated piece collaboration
• #229 — Standalone backend server application

The distributed machinery is proven. Two Oolois on two laptops, one hosting, one connected, editing shared state with undo reaching across the wire and respecting each other's work. What's missing is everything that governs who may do what: invitations, single-use tokens, deep links, JWT identity, role-based access, a host-side collaborator registry, and a piece picker that shows a guest their own slice of a catalogue rather than someone else's filesystem.

There's an obvious objection to doing this now. Collaboration is the exception. I fully expect the overwhelming majority of Ooloi users to run it standalone on one machine and never invite anybody to anything. Why finish the exception before the rule?

Precisely because it is the exception. Work that sits half-done at the edge of a system does not stay quiet. It surfaces as a special case in every subsequent decision, and it surfaces at the worst moment, which is when you're concentrating on something else. Finishing it now means never thinking about it again. When the engraving work begins, the access model will be behind me rather than beside me, and single-user operation will be what it already is architecturally: a collaboration group whose size happens to be 1.

A word about #229, because its title invites exactly the wrong inference. The standalone server isn't a second product. Not a separate edition, not a server variant, not a codebase carrying features the desktop application lacks. It's the backend half of ordinary Ooloi – the same backend, the same components, the same behaviour – packaged to run on its own: in the cloud, on a conservatory's machine, on a collaborator's laptop in another city. There's no new functionality involved. The administrator connects to it as a client, through the same authentication path as anyone else, which is the whole reason it comes after #136 rather than before.

The substrate

• #7 — Plugin system.
• #8 — Skija integration.

Ooloi 'eats its own soup'. The formatters that draw a page are plugins, on exactly the same terms as anything a third party might write: the same API, the same performance, the same access. There's no privileged internal path that the public one imitates. This is not a gesture towards openness; it's the mechanism by which engraving conventions stay arguable. If you disagree with how Ooloi slopes a beam or hangs a secondary, and the settings provided aren't enough or your formatting philosophy is different, you can replace the formatter, in whichever JVM language you prefer, and Ooloi doesn't notice the difference.

Which is why the plugin layer precedes the drawing. It also precedes MusicXML, because the importer is itself a plugin, and it'll be the first serious test of whether the plugin surface is genuinely sufficient rather than merely declared to be.

Skija brings Skia into Ooloi: the graphics engine behind Chrome, Android and Flutter, and the third incarnation of a lineage that runs back through AlphaMask to QuickDraw GX, which is where Igor Engraver began. I have written about that circle before. What matters here is narrower. Until Skija is in, Ooloi cannot draw anything at all. Not a stave, not a notehead, not the small music example that ought to sit inside a preferences dialog showing you what a setting actually does to the page. The layout windows currently open onto a considered and entirely empty surface. Skija is what fills them.

The page, assembled

• #6 — Hierarchical rendering pipeline.

The full specification is in ADR-0028 and I will not rehearse it here. What's worth stating is the order of implementation, because it reads rather like a page assembling itself:

First blank pages. Then the text on them: titles, headers, footers, page numbers. Then systems, with their instrument names, brackets and braces. Then staves and their staff lines. Then the measures on those staves, which is where noteheads, stems, flags, dots and accidentals first appear.

And spanners last. Ties, slurs, hairpins, lyrics, ottavas, and above all beams, which are the hardest of them and the most revealing of a system's quality.

That sequence isn't an implementation convenience. It's the pipeline's own structure: everything that can be computed independently, computed first and in parallel, and everything that depends on final positions deferred until those positions are fixed. The page is built the way the architecture says a page is built.

The Turn

Here is what actually changes, and it's not the subject matter.

For two years an argument could be settled by running something. Does the traversal allocate? Measure it. Does the accidental algorithm handle a grace note at a barline under a hierarchical key override? There is a test, and it either passes or it doesn't. Determinism is a property you can demonstrate. When I wrote that two supposedly intractable problems had collapsed into ordinary algorithms, the claim was checkable, and anyone who doubted it could check it.

Nothing in the next phase works that way.

No test will tell me a beam slope is beautiful. No suite will fail because a slur's curvature is slightly graceless, or because the white space on a page reads as mean rather than generous. The machinery that has caught every error for two years is about to fall silent on precisely the questions that matter most, and the only instrument left is a musician's eye. Mine first. Then, with any luck, other people's.

And the ground underfoot isn't solid in the way the engine's was. Staff notation is roughly a thousand years old. Printed engraving as a craft is five hundred. The copperplate house styles I'm actually implementing are perhaps two hundred and fifty. Each layer left conventions behind. They don't agree with one another, and they don't always agree with themselves: Ross devotes some fifty pages to beaming and contradicts himself more than once within them, and where Ross and Gould differ, they differ because the profession differs. Bärenreiter is not Durand. Neither is wrong.

So the design consequence was settled in advance. Engraving rules live as editable data rather than as conditionals buried in source. House styles are configuration. Formatters are replaceable. Where taste genuinely differs, Ooloi takes a position and makes the position adjustable, because the alternative is to pretend a live craft is a solved one.

That's the work now: the objective machinery in service of something irreducibly subjective. It's the part I have been waiting two years for, and it's also the part where merely being right is no longer sufficient.

Tempo

A practical note. I've just begun a new client placement, with a complex system to get into production, and it's absorbing a great deal of attention. On top of that my AWS DevOps Professional certification is due for renewal, and I take the AWS exams seriously enough to actually study for them rather than turn up and hope. The next month or so will therefore be slower here than the last three have been.

This does not worry me in the slightest. The summer's pace was fast and, if anything, accelerating: subsystem after subsystem closed and stopped asking to be thought about again. The project's in a good place. A quiet month against that background is a quiet month, not a stall.

Coda

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.