​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.

I've noticed people on various web forums asking when they'll see Ooloi render notation. Fair question.

Not yet. Foundation work comes first: the stuff that makes it possible to draw music efficiently. When the rendering implementation begins, the blog will shift from infrastructure to musical decisions: how things sit, straddle, and hang.

Why this approach? This is open-source software built for decades of durability. It's not a commercial product racing as fast as possible to market. No competitors to 'eliminate', no users to 'capture'. Just correct foundations before visible output. Come back in a year or so: the conversation will be about music by then.

What 'correct' means: Nested tuplets to arbitrary depth with exact arithmetic, for instance. No ticks, no fudging, no approximations. The kind of precision that takes time to build right. And tuplets are just one small example.

Single-user first. Ooloi is designed for one person working on one score. Collaboration features are a byproduct of the architecture, not the main focus. The distributed design is about clean separation of concerns and deployment flexibility: collaboration just happens to work because the architecture supports it.

Do I care if people understandably say 'I'll believe it when I see it'? No. 

The work continues.

Research for Ooloi’s input system turned up something I hadn’t expected. Igor Engraver’s Flow Mode – the modal, stateful keyboard entry that defined its way of working – has never been recreated. Not by Dorico, not by Sibelius, not by Finale, nor by any of the open-source projects. Twenty-three years on, the idea has simply vanished.

Flow Mode was straightforward. You pressed “.” once and staccato stayed active; crescendo and diminuendo wedges and slurs extended naturally as you continued writing. The commands mapped directly to the symbols – intuitive, fast, and oddly satisfying. When Igor died of business failure in 2001, the method died with it. There is no academic record, no terminology, no sign that anyone even remembered it existed. I had fully expected other programs to have copied this feature; it gives a five- to ten-fold increase in music-entry speed.

Web forums on notation are full of people asking for faster, more fluent keyboard entry, yet without the vocabulary to describe what they want. They are looking for something they have never seen.

So this part of Ooloi isn’t innovation; it’s recovery. The system worked. It was lost for reasons that had nothing to do with design. The decision to re-implement it, and the details, are now recorded in ADR-0032: Ooloi Flow Mode.
​
What remains is to implement it – and to find Magnus Johansson, who just might still have the user manual.

​I'm disappointed with the functional programming community. I was expecting higher-level thinking – freer thinking, commensurate with the intellectual freedom Clojure itself offers – but the atmosphere proved to be a shallow puddle of sectarianism​. That probably has its reasons – being marginalised as a community is probably one of them – but the end result remains unchanged.

The patterns are unmistakable. Knowledge as gatekeeping: the endless monad tutorial phenomenon, where every advocate believes they can explain monads better than everyone else, typically through increasingly baroque metaphors involving burritos, space suits, or elephants. This isn't pedagogy; it's ritual initiation. The complexity serves a social function – maintaining boundaries between insiders and outsiders.

Purity as virtue signalling: debates about whether using `IO` makes you impure, whether exceptions violate functional principles, whether mutation in bounded contexts is acceptable. These discussions frame technical trade-offs as moral categories, as though architectural design were a moral discipline rather than an engineering one. The language reveals it – clean, pure, disciplined versus dirty, impure, undisciplined. This is religious vocabulary applied to software engineering.

Terminology as tribal marker: deliberate retention of academic terminology when simpler terms exist. Endofunctor, catamorphism, anamorphism when 'map over containers', 'fold', 'unfold' would suffice. The obscurity is the point – it establishes hierarchy and demonstrates membership.

The emphasis falls on mathematical elegance rather than problem-solving. The question isn't Does this help ship software but Is this theoretically sound. People who can recite monad laws but have never shipped a product receive more status than developers applying functional patterns to solve actual problems.

Then there's the missionary behaviour: the conviction that imperative programmers need conversion. The framework isn't Here's another useful tool but You're doing it wrong until you see the light. This creates antagonism rather than adoption.

Being marginalised as a community probably explains some of this – defensive posture manifesting as increased boundary enforcement, which creates insider/outsider distinctions, which enables status hierarchies based on doctrinal purity. But understanding the cause doesn't change the result, and it doesn't make the behaviour intellectually rigorous or practically useful.

​Here's the substantive issue: finding Ooloi collaborators in FP communities is statistically improbable because very few people occupy my intersection point between various disciplines.

Music notation requires an understanding of compositional structure, engraving conventions, and how musicians actually work. Functional architecture requires a sophisticated understanding of immutability, higher-order functions, transducers, STM transactions, and compositional patterns. Backend infrastructure requires a willingness to work on unglamorous problems like endpoint resolution and temporal traversal rather than visible features, and in Ooloi's case, an understanding of server technology and secure cloud operations.

The population at that intersection is approximately one.

FP communities might yield people who appreciate my transducer implementations or STM transaction handling. But they won't understand why endpoint resolution for slurs matters, how temporal traversal serves musical structure, or what makes intelligent engraving different from geometric placement. The domain expertise is orthogonal to FP community concentration.

The inverse holds equally: musicians who understand notation deeply rarely have the architectural sophistication to work on Ooloi's core, and even fewer would find satisfaction in building infrastructure rather than using tools.

I've worked outside the FP community all my life. Functional programming is a tool, not a (monadic) religion. (And why are monadic and nomadic so similar?) Why join the community now, when the benefits are unclear and the costs palpable?

​The technical response is what I call the Latin strategy: making Ooloi's core a stable foundation for a plugin ecosystem. Build the architectural core once in Clojure, then let developers in other JVM languages contribute via plugins without needing to understand the underlying functional implementation. I've written about this approach in Penitenziagite!, so I won't rehearse it here.

Elektra's tragedy is total consumption by purpose. She becomes nothing but the task, and when it completes, there's nothing left because she permitted no existence beyond vengeance. She dances herself to death.

I'm certainly not doing that. Ooloi is a project, not my entire existence. Sustainable completion means finishing the backend, documenting it clearly, releasing it, and then moving on. The work stands independently; I remain separate from it.

I'll finish Ooloi's core architecture working alone, not because I prefer isolation, but because collaboration at this intersection point is impractical. The resolve comes from accepting reality rather than pretending community exists where it doesn't.

The backend is complete. The transducer-based timewalker is fast, tight, and efficient. Endpoint resolution handles slurs and ties correctly. Nearly nineteen thousand tests pass. Vector Path Descriptors enable elegant client-server communication.

Then comes plugin architecture, and seeing whether anyone finds Ooloi useful. If they do, excellent. If they don't, I built something architecturally sound and learned what I needed to learn.

Either way, the work speaks for itself. And I continue existing beyond it.

Nun denn, allein!

Every notation program eventually reaches the same constraint: the interface and the layout engine compete for control of time. When they do, the system freezes.

ADR-0031 defines how Ooloi avoids that conflict. Local actions such as editing, scrolling, and selection remain inside the JavaFX event system, which responds instantly. Network events, like collaborative edits or layout changes, are handled separately, through a dedicated Event Router that never blocks the interface.

For engravers, this means something simple but long overdue: editing and scrolling stay smooth, no matter how large or complex the score, and no matter who else is working on it.

The document doesn’t describe a finished feature; it describes the foundation that makes such responsiveness possible. From this point on, Ooloi’s design rests on a single rule: the interface must never wait for the network, and the network must never interrupt the interface.

Full text → ADR-0031: Frontend Event-Driven Architecture

Licensing isn't a legal appendix to the codebase; it's part of the architecture. A distributed system defines its boundaries through protocols. A licence does the same, only in law instead of syntax.

Open source isn't marketing; it's a contract of trust. You keep the code open not because you must, but because integrity demands it. You protect the name not to hoard it, but to prevent confusion.

Ooloi's licence now mirrors its architecture: clear boundaries, open interfaces, and a shared foundation for whatever might be built next.

Clarity and transparency.

Saving this complete piece took 1.3 seconds; loading it, 3.3 seconds. The resulting file was 172 KB – smaller than a single page of PDF. The piece does not yet include graphical information (layout, coordinates, glyphs), which would roughly double the size or more, but at these levels it makes no practical difference. Even if it becomes ten times larger, it's still of no consequence. The numbers are that good.

Streaming export (MIDI or MusicXML) completed in 1.25 seconds, using under 10 MB of memory. Even full materialisation of every internal element peaked at 244 MB, far below what such scores normally require.

​Behind those figures lies the traversal engine that makes them possible. The full 520 000-pitch traversal completed in 0.58 seconds – roughly one million pitches per second. Cache repairs and dependency updates finished in 1–5 ms. Endpoint searches (for ties and slurs) are blazingly fast too, obviating the need for direct pointers.

For comparison, a score of this magnitude would have strained the limits of any existing notation program. Finale or Sibelius might take tens of seconds – sometimes minutes – to perform an equivalent operation. Ooloi completes the same structural pass between heartbeats.

What makes this possible is not optimisation trickery but architecture: immutable musical data, transducer-based traversal, and disciplined cache coherence across every layer. The system streams; it does not churn.

​For composers and engravers, these results suggest something once thought impossible – that even a full Wagnerian tutti might one day update instantly after an edit. Everything so far indicates that this should be achievable, not through hardware brute force but through architectural clarity.

For developers, the message is the same: a purely functional, streaming model can handle orchestral-scale data in constant memory, with sub-millisecond locality.

As far as I know, this is the first time a professional notation system has demonstrated real-time traversal of a Wagner-scale score with constant memory and sub-second exports. The invisible foundation – the hard part – is finished.

​All tests were run on a 2017 MacBook Pro with a 2.2 GHz six-core Intel i7 processor and 16 GB of RAM. A modern 2025 laptop or workstation would almost certainly halve every number reported here, and perhaps more. What feels instantaneous today will, in a few years, be beyond perception.

​Full benchmark results here.

Still on track towards that goal of smooth scrolling through the Elektra recognition scene.

​In Umberto Eco's The Name of the Rose, a mad monk wanders through the monastery corridors shouting 'Penitenziagite!' – corrupted Latin mixed with vernacular, incomprehensible noise that might be prophecy or might be madness. Communication fails not from lack of content, but from linguistic confusion. The message is lost in translation.

Software architectures shout 'Penitenziagite!' constantly, and we've grown so accustomed to the noise that we mistake it for communication.

​When you write a plugin for a system, you shouldn't need to learn the implementation language. That seems obvious, yet most software makes exactly that demand. Functional programming libraries leak monads into Java APIs. Object-oriented frameworks force functional concepts into awkward method chains. Every language boundary becomes a barrier, every abstraction a translation exercise.

The pattern is familiar:

• Methods that expose internal implementation details externally
• APIs that assume you think in the framework's paradigm
• Documentation that requires understanding the core's language to extend the edges
• Forced mental context-switching when crossing boundaries
• 'Just learn our language' presented as the solution rather than the problem

This isn't malice. It's accidental linguistic imperialism – systems that never considered the difference between internal precision and external accessibility.

​The core cannot compromise. If mutability seeps in, if temporal coordination is abandoned for convenience, the whole thesis fails. The hard problems must be solved correctly, once, in the protected centre.

But the perimeter cannot be closed. If only Clojure developers can extend Ooloi, adoption remains limited to those willing to learn functional programming. The architectural advantages – provable speedup on reflow operations, proper concurrent editing, elimination of state-corruption bugs – must be accessible without requiring conversion.

This isn't architectural fussiness. It's the difference between a system that proves functional programming solves these problems and one that merely claims it whilst forcing everyone through the same narrow gate.

Consider the alternative: most cross-language projects either compromise the core's purity to make external access easier, or maintain purity whilst making extension nearly impossible. Both approaches fail – the first produces unreliable systems, the second produces unused ones.

​When I say plugins are first-class citizens, I mean it precisely:

• Full API access: Plugins can do anything internal code can do
• No performance penalty: JVM interop means native speed across boundaries  
• Equal capabilities: The implementation language determines developer experience, not power
• Designed from the start: The architecture was built with plugins as equals, not added later

Your Java plugin implementing custom layout rules operates with the same capabilities as Clojure core code. The boundary is invisible – just clean interfaces and reliable contracts.

Work continues: the monastery's standards hold. The architecture neither shouts incomprehensibly nor demands conversion. There's no Inquisition burning engraving monks at the stake.

The point isn't piety; it's architecture that stays intelligible.

Just clarity, properly structured.

– William of Baskerville

Last week I wrote about flipping the Staff→Voice→Measure hierarchy to Staff→Measure→Voice. The structural reasons were sound, but I'd estimated a week for the implementation. Forty files to touch, thousands of tests to update, the whole spine of the system. With a 1:1 ratio of code to tests, that's rather a lot of surface area to cover. This usually means a lot of pain.

The actual time: four hours.

Claude Code's systematic approach made the difference. Seven discrete steps, continuous test validation, zero functionality regression. Tests failed as expected during refactoring, but the effort to fix them was absolutely minimal. This wasn't vibe coding; I controlled the process carefully, directing each step. Yet even with that careful oversight, the work required was remarkably little. Claude 4.5, being new and even more capable, may well have been key here.

The result was better than expected as well: 30–99% less allocation through transducer-based lazy sequences, 211 fewer lines of code, clearer logic throughout. What surprises me isn't that AI-assisted development helped; it's the magnitude. A tenth of the expected time isn't incremental improvement. That's a different category of capability entirely.

Now on to some small bits and bobs before the real work on the client starts: windows, drawing, printing, etc.

​This seemed sensible at first. We were thinking about voices as independent melodic lines that happen to align at measure boundaries. We even structured it this way to handle ossia staves (those little alternative passages that appear for a few measures then disappear).

But that's not how notation actually works. Measures are the organising unit. Voices are just 'simultaneous material in this measure'.

​Measures contain voices. Problem solved: 'give me everything in measure 5' is just a direct lookup. All the voices are right there.

And ossia staves? Actually clearer in this model. A staff just enters at measure 17 and exits at measure 20. Clean and explicit.

When your data structure fights the domain, everything becomes harder. Performance tricks, validation logic, traversal algorithms – they all work around the mismatch instead of with the model.

When the structure matches reality, everything becomes easier. The formatting code that sparked this whole thing? It'll be trivial now. Just iterate measures, render their voices. Done.

This is one of those changes that seems obvious in hindsight but not when you're in the middle of building. You pick a structure that appears reasonable, you build on it, and only later when you try to use it do you realise the foundation is slightly crooked.

The question is whether you have the time and space to fix it, and whether you have the honesty to admit it needs fixing.

I'm fortunate. I have the time. This project doesn't require me to pretend otherwise. And if the page keeps telling me the model is lying, I'll keep listening.