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.

There are days in Ooloi’s development when I feel like the Donald. Not that Donald. Donald Knuth. There's something very real to that comparison, even though it can be seen as presumptuous. Why do I compare myself with a computing giant?

Knuth faced typesetting systems that were brittle, ad hoc, and incapable of scaling to real demands. He didn’t patch; he rebuilt the foundations. Out came deterministic algorithms, the box–glue model, and a system that still sets type decades later.

I’m in a similar place. Music notation software has been compromised for forty years: mutable object graphs, procedural hacks, import/export traps. It works until you open Eine Alpensinfonie or Lontano – then it collapses.

So Ooloi is built the way TeX was:

• Foundations first. Ooloi has been in development for a year, part-time. No notes have appeared on screen yet, but that isn’t delay, it’s sequence. The first phase was concurrency, traversal, contracts: all the invisible machinery that must be right before visible music can exist.
• Immutability as discipline. Where TeX used deterministic boxes and glue, Ooloi uses persistent data structures and STM. Both eliminate state leakage as a class of bugs.
• Correctness as architecture. In TeX, line-breaking is provably optimal. In Ooloi, sharing and traversal are mathematically guaranteed by immutability and functional design.

And even a year isn’t slow, considering what's been implemented in that time. In Clojure, as in Lisps generally, progress is faster, not slower, because the language doesn’t get in the way. Architectural changes that would take months in procedural or OO systems collapse into days when immutability is the default. In Lisps I feel unrestricted from the usual … bullshit.

​I'm one of the world's most committed anti-religious people. Despite decades at organ consoles in churches and cathedrals, I stand with Hitchens: religion is humanity's adolescent phase, something we need to outgrow. Its influence is fundamentally harmful.

But when I read something like How Lisp Became God's Own Programming Language, I completely understand the reverence the author describes. There's something about Lisp – and Clojure – that creates what you can only call a transcendental response. Nothing actually transcendental happens, of course, but the feeling is real.

What Lisp gives you is freedom. I've written about 'windsurfing through parentheses' before, and the metaphor sticks because it captures something essential. Most programmers are chained to the oars of enterprise slave galleys, with CTOs yelling 'RAMMING SPEED!' like that brilliant scene from Ben-Hur. Meanwhile, those of us who've found Lisp are windsurfing in circles around them, enjoying a freedom they can barely imagine.

The discovery feels like Dave Bowman meeting the monolith: 'My God... it's full of stars!' That vertigo when you realise this thing's inner dimensions vastly exceed its outer ones. Lisp isn't transcendental, but it works like a star gate in both senses. The language doesn't get in your way, and it opens new ways of thinking. At the same time, it's so simple that complexity becomes manageable.

I remember that August 1979 BYTE magazine perfectly. The cover promised mysteries, the articles delivered. I couldn't wait to start implementing what they described – eventually doing it in 6502 assembler, using an assembler I'd written in BASIC.

Everything clicked, even as a teenager. This was real freedom, expressed as code.

Years later, I wrote HotLisp (or 'HotLips' – M.A.S.H. was huge then) for the Royal College of Music in Stockholm. It was incredibly ambitious: a full Common Lisp that treated MIDI events as first-class citizens. Looking back, I see this as the beginning of what became Igor Engraver – integrating music directly into the computational core. We used it to control our Synclavier and MIDI synths whilst teaching algorithmic composition to advanced students at the Royal Academy.

The Two-Bit History article nails something important about Lisp's mystique. It traces the evolution from McCarthy's 'elegant mathematical system' through AI research, Lisp machines, and SICP's role in making it the language that 'teaches you programming's hidden secrets'. Each phase built the reputation.

What the article doesn't cover is the educational betrayal that followed. Computer science departments got it right for a while – they taught Scheme as a first language because it let students focus on learning algorithms rather than wrestling with syntax. Pure freedom to think about problems. Then Java Enterprise was foisted upon the world, the departments caved in, and they started churning out galley slaves instead of computer scientists. I see this as nothing short of high treason.

But here's what really matters: that freedom has evolved in Clojure. Rich Hickey didn't just bring Lisp to the JVM – he solved problems that even Common Lisp couldn't handle elegantly. Those immutable data structures aren't academic toys; they're game changers that eliminate whole categories of bugs whilst making concurrency and parallelism natural instead of terrifying. The effects ripple out: undo/redo becomes trivial, and the JVM gives genuine multi-platform reach.

This isn't just improvement – it's architectural breakthrough disguised as evolution. Clojure keeps Lisp's essential quality (that feeling of discovering how programming should work) whilst solving modern problems McCarthy couldn't have anticipated.

The poor souls in corporate Java shops keep rowing, occasionally granted small mercies as functional concepts trickle in – hints of the freedom they're missing.

I wish they could experience what we know: programming doesn't have to feel like industrial labour. There's a way of working where ideas flow directly into code, where the language becomes transparent, where you stop fighting tools and start windsurfing through solutions.

Maybe that's the point. As McCarthy noted in 1980, Lisp survives not because programmers grudgingly accept it as the best tool for each job, but because it hits 'some kind of local optimum in programming language space'. It endures even though most programmers never touch it, sustained by reports from those who've experienced its particular form of computational enlightenment.

Until we can imagine God creating the world with some newer language – and I doubt that day is coming soon – Lisp isn't going anywhere.

Read the full article at Two-Bit History: https://twobithistory.org/2018/10/14/lisp.html

We tested it.

50,000 musical objects: 14.5KB total on disk. Not megabytes. Kilobytes. That's not even 0.3 bytes per note.

MusicXML equivalent: ~50MB. That's 3500x larger.

Save/load time: about 250ms on a crappy 2017 MacBook Pro.

These are just the core musical objects - pitches, rests, chords, articulations. A complete score adds instruments, parts, staves, layout data, and more. But the efficiency gains indicate what's possible when you eliminate redundancy at the foundation.

The venerable technique hash-consing (1958, from LISP and symbolic computation) works. Of course it does – and how!

​Article on implications coming.

Musical scores are full of repetition. In a symphony, middle C can appear thousands of times, quarter notes dominate, and the same staccato mark is scattered across every instrument. Most notation software allocates a separate object for each of these occurrences. That means thousands of identical objects, all taking memory and I/O bandwidth for no reason.

Ooloi doesn't.

With ADR-0029, we have implemented selective hash-consing: identical immutable musical objects are represented by the same instance. The same C4, the same staccato, the same quarter note: one object, shared system-wide.

Finishing the statistics infrastructure naturally led to thinking about the next architectural milestone: the rendering pipeline. This is the mechanism that determines what happens when someone clicks into a score to add a note, and how that change propagates through the system.

The design is complete. That in itself is an important milestone, as this is the very foundation on which Ooloi's performance ultimately depends. Everything hinges upon it.

Traditional notation software recalculates entire scores when a single element changes. Dense passages in works like Strauss's Elektra bring systems to a halt because every operation is sequential and single-threaded. The reason for this is that parallelism is very difficult to do with mutable state, which is the traditional approach. Scalability often becomes an issue, with diminishing returns as a result.

Ooloi takes the opposite approach and chooses the Clojure way instead, with immutable state. With this, it is comparatively easy to distribute formatting work across all available CPU cores and use them fully and linearly.

Every user action – whether adding a single note or adjusting spacing – thus becomes part of a coordinated cascade where each stage can run in true parallel across all available cores.
​
The goal is straightforward: responsive editing even in the heaviest repertoire.

ADR-0028 specifies the pipeline in five stages, separating connecting from non-connecting elements and applying a clear fan-out/fan-in pattern.

1. Minimum Widths (Fan-out): Each measure independently calculates spatial requirements – collision boundaries only. Results are immutable and persist until the content changes.
2. Vertical Raster (Fan-in): The MeasureStackFormatter collects widths, generates result rasters, and records both minimum and ideal widths. This prepares the ground for spacing optimisation.
3. Non-Connecting Elements (Fan-out): Independent symbols – noteheads, accidentals, articulations, dynamics – are prepared in parallel. They don't need finalised atom positions.
4. Discomfort Minimisation: Iterative optimisation adjusts widths and system breaks to reduce proportional distortion. No layout changes occur after this stage. From here on, positions are fixed.
5. Connecting Elements​: Slurs, ties, beams, hairpins, and glissandi are drawn only once final positions are known. Sequential coordination ensures continuity across measures and systems.

This separation allows Ooloi to exploit parallelism where possible and enforce order where necessary.

Formatting in Ooloi is plugin-driven. Core elements such as notes and beams are implemented through the same interfaces available to extensions.
​
Plugins can participate in different stages depending on their needs:

• Spacing hook (Stage 1) for collision boundaries
• Paint hook (Stage 3) for independent elements
• Connect hook (Stage 5) for elements spanning multiple atoms

Simple articulations may use only the first two; beams may require all three. This uniform model ensures extensibility without compromising performance.

The optimisation engine measures deviation from ideal proportions across measures, systems, and pages. Improvements multiply: small gains in multiple places compound into significant overall reductions. Hard constraints such as manual breaks provide natural stopping points.
​
This replaces arbitrary iteration limits with a principled measure of quality.

Claypoole provides efficient thread-pool execution, delivering significant speed-ups over built-in Clojure parallelism. STM transactions keep operations atomic while allowing concurrency inside each stage. Cooperative cancellation ensures that rapid user input remains responsive.
​
The system treats a single user as a 'collaboration network of one'. The same infrastructure that supports multi-user editing ensures smooth interaction for individuals.

This pipeline is the structural core that should make scrolling through Elektra or Ligeti's Requiem as fluid as editing a Gnossienne by Satie.
​
The specification is complete. Implementation begins as soon as the current phase closes. Ooloi's promise of responsive, professional-scale notation depends on it.

​Scary stuff.

​Full specification: ADR-0028: Hierarchical Rendering Pipeline with Plugin-Based Formatters

​After a year of building infrastructure, it seemed worth finding out whether it actually worked.
The test was simple: create a million rests and see what happened. One operation –

​– repeated until either something broke or the numbers settled.

First experiment: one client, one thread, a million sequential calls. This was on a 2017 MacBook Pro, so not exactly cutting-edge hardware.

Every call succeeded. Average execution time was 35 microseconds. Memory stayed at 112 MB without drifting upwards. Garbage collection remained in the young generation. Thread count didn't move. Zero errors.
​
Nothing dramatic, which was the point.

Second test: four threads on one client, 250,000 calls each. Another million operations, but with some concurrency this time.

Same result. All calls succeeded, memory stayed flat, garbage collection behaved, threads were stable. Still zero errors.
​
This level of concurrency should be unremarkable for any serious system. It was.

Third experiment: ten clients, four threads each. Forty threads total – enough to make the laptop work.

Average call times went up to 246 microseconds, but everything else held steady. Memory stable, garbage collection well-behaved, threads disciplined. Error count still zero.
​
Same 2017 laptop that started the tests.

From one thread to forty, from 35 microseconds to 246, the pattern was consistent. The system handled load without breaking.
​
These were only raw API calls, not STM transactions with musical logic and collaboration on top. Those will be next. For now, the figures suggest the foundations are fast, steady, and ready to carry more.

After a year of working only on foundations – work that must succeed by disappearing – we are finally ready to turn to visible things. Music, for instance.

This Grafana dashboard shows eighteen minutes of a distributed system handling real client connections. The server sits at a 44 MB baseline and stays there: no memory growth, no thread churn, zero old-generation garbage collections. The jump to 83 MB comes not from client load, but from Grafana itself polling for statistics.

Those numbers matter because they validate architectural decisions made months ago. Functional programming principles, STM coordination, gRPC infrastructure: all the invisible work that had to be right before building anything a user might see.

Stable thread pools. Clean memory management. Efficient client handling. Nothing dramatic – just solid enough to carry what comes next.

The system no longer needs proving. Now it needs notes.

Yesterday’s post was about pitch transposition in Ooloi: how an old Igor Engraver function (printed on a t-shirt, of all places) came back to life in a new context. That work didn’t just solve the mechanics of shifting notes up and down; it reopened the larger question of playback. How do you hear microtonality and advanced humanisation without drowning in technical workarounds?

In Igor, the answer was MIDI. Notes were split across channels, bent into place, reassigned constantly. The result worked, but at the cost of complexity: a “DNA soup” of allocations and pitch-bend tricks. Ingenious, but exhausting.

Ooloi makes a different choice.

With ADR-0027: Plugin-Based Audio Architecture, we draw a line: no MIDI output in the core, no audio generation in the backend. Playback is done entirely through plugins in the frontend. If you want VST/AU instruments, SoundFonts, OSC, or any other output path, you install a plugin. The backend remains what it should be: musical data, collaboration, structure.

This is not just simplification, it’s liberation.

• Microtonality is handled directly in the data model, then played back by plugins without channel gymnastics.
• Humanisation is no longer bound to 7-bit controllers; plugins can drive modern sample libraries with full parameter precision.
• Collaboration becomes clearer: the backend never streams audio, never mangles MIDI, never compromises. Each client handles its own sound.

Put bluntly: we no longer need MIDI as an output protocol. It served its time. For professionals who need nuanced playback, orchestral realism, or contemporary techniques, we now have better tools: VST/AU plugins and beyond.

That said, MIDI output isn’t forbidden. If anyone needs it, a frontend plugin can provide it. For tonal music it will work fine. But if you want advanced humanisation or microtonality, you’ll inherit the need for all the old machinery: channel allocation, pitch-bend acrobatics, the DNA soup. That’s exactly why Ooloi itself doesn’t touch it.

The logic is simple: Ooloi’s core manages music, not sound. Plugins handle playback, and in doing so, they do it better than MIDI ever could.

The DNA soup is gone. What remains is clean, modern, and far more powerful.

​Our solution was elegantly brutal: we seized complete control of attached MIDI units and employed pitch bend to achieve microtonal accuracy. This required distributing notes across MIDI channels according to their pitch bend requirements, using register allocation algorithms borrowed from compiler technology. In a chord containing one microtonally altered note, that note would play on a different channel from its companions. We changed patches frantically and maintained no fixed relationship between instruments and channels – everything existed in a kind of 'DNA soup' where resources were allocated dynamically as needed.

This approach let us extract far more than the nominal sixteen-channel limit from typical MIDI synthesisers. We maintained detailed specifications for every common synthesiser on the market, including how to balance dynamics and handle idiosyncratic behaviours. 

​The system's sophistication extended well beyond pure pitch calculations. When my opera The Maids was commissioned by the Royal Stockholm Opera, I spent considerable time crafting realistic rehearsal tapes. Everything I learned from that process was automated into Igor's playback engine.

We also collaborated with the KTH Royal Institute of Technology Musical Acoustics department, led by the legendary Johan Sundberg, whose research had quantified subtle but crucial performance characteristics. Those famous four milliseconds – the consistent temporal offset between soloists and accompaniment in professional orchestras – found their way into our algorithms. Such details proved particularly effective with Schönberg's Hauptstimme markings (𝆦) or similar solo indicators.

We also developed what my composer colleague Anders Hillborg and I privately called 'first performance prophylaxis' – a deliciously cruel setting that simulated the sound of musicians who hadn't practiced. In other words, the kind of sound landscape any composer is used to hearing at a first orchestral rehearsal of a new piece and which always makes you doubt your own talent. Turn this setting up, and you'd hear a characteristically dreadful youth orchestra. Turn it down completely, and you'd get the robotic precision that plagued every other MIDI system. Rather like Karl Richter's Baroque organ recordings.

The humanisation algorithms incorporated realistic instrumental limitations. Passages written too quickly for an instrument would skip notes convincingly. We modelled the typical rhythmic hierarchy of orchestral sections: percussion most precise, then brass, then woodwinds, with strings bringing up the rear. Instruments were panned to their proper orchestral seating positions. Piccolo trills were faster than tuba trills. The result was startlingly realistic, particularly by 1996 standards.

​Now, twenty-five years later, that laundry basket discovery has culminated in ADR 0026: Pitch Representation and Operations, documenting Ooloi's comprehensive pitch representation system. The original Common Lisp has been reborn as Clojure code, with string-based pitch notation ("C#4+25") serving as the canonical format and a factory-based transposition system supporting both chromatic and diatonic modes.

The string representation offers several advantages: compact memory usage for large orchestral scores, direct human readability for debugging, and seamless integration with parsing and caching systems. Most crucially, it supports arbitrary microtonal deviations, something that remains problematic in most contemporary notation software.

The factory pattern generates specialised transposition functions that encapsulate their musical behavior rules through closures. Rather than repeatedly passing configuration parameters, the factory creates efficient, composable functions that understand their specific musical contexts. A diatonic transposer preserves letter-name relationships; a chromatic transposer produces frequency-accurate results with canonical spellings.

The t-shirt in my laundry basket represented more than nostalgic memorabilia; it was unfinished business. That higher-order function embodied a sophisticated understanding of musical mathematics that took a long time to develop and seconds for an AI to recognise as architecturally significant.

Now, with Ooloi's pitch operations properly documented and implemented, that business approaches completion. The code has evolved from promotional garment to production system, carrying forward those insights from 25 years ago into a new, modern technological context.

It's exciting. And still a little unnerving.

Three tests left on the visibility work. After that, this part of the system is done.

It’s taken a few weeks to get the final bits of the gRPC server/client interaction implemented, but it now feels solid. The server reliably and efficiently handles all the complex aspects of live clients connecting, disconnecting, and communicating locally or over the inherently chaotic internet. 

With that done, the focus is now on what is called observability: being able to see what's going on inside. In other words, server statistics. We’re now tracking server-wide and per-client metrics: connections, API call rates, message sizes, event streaming, queue overflows. Endpoints can return JSON during development or Prometheus format in production. Content negotiation is automatic, or you can force a format with a query parameter. No new tools to learn. Grafana dashboards work straight away.

Why this matters for musicians: research has shown that in collaborative settings, users prefer a notation program that lets them work together over one with the most features. That says everything about how poorly existing software supports collaboration. It’s treated as an optional extra, if it exists at all.

Ooloi is built differently. Collaboration is not bolted on afterwards but designed into the system from the start. If event queues slow or connections drop, collaboration breaks down. A slur added on one screen never appears on another, or two edits collide and the score diverges. The statistics make these problems visible. They show when the system is stressed, when clients are falling behind, when the score risks drifting out of alignment. In short, they make collaboration trustworthy.

And unlike the current trade-offs, Ooloi isn’t choosing collaboration instead of notational depth. It is designed to be both: a serious, advanced notation platform that also makes shared editing reliable.

The same architecture also opens up another possibility. Because Ooloi is client/server, it can stream smoothly scrolling scores in real time. That makes digital music stands for ensembles or orchestras feasible. It’s not the main focus, but it’s there: the professional counterpart to the school-level collaboration studies.

Three tests left. Once they pass, the intricate server machinery will be visible. And visibility is the first condition for trust.

Ooloi is moving fast. Architectural decisions, implementation milestones, and the long road toward open-source release deserve a channel that isn’t buried in blog posts or scattered across updates.

The Ooloi Newsletter is that channel. It’s for composers frustrated with the lag of existing software, musicians curious about what modern architecture makes possible, educators and publishers planning future workflows, and developers who want to see Clojure’s STM, transducers, and gRPC applied directly to real musical problems.

This isn’t marketing. There’s nothing to hype, no metrics to chase. It’s progress – the daily work of turning musical thinking into software design. Updates arrive when there’s something real to report: once or twice weekly in active phases, slower during architectural deep work.

Expect honest accounts of what’s been built, what broke, and why decisions were made. Technical when it illuminates music, musical when it drives architecture. No jargon for its own sake, and no dumbing down.

If that sounds useful, subscribe at buttondown.com/ooloi.

The thread from FrankenScore to Ooloi continues. You’re welcome to follow it.

​Igor's demise taught me harsh lessons about market timing. When you create genuinely superior tools because existing software actively gets in your way, you discover that technical excellence alone can't guarantee survival.

Igor actually started as freeware – that was my original vision. The VCs wanted features, revenue streams, market capture. I wanted musicians to have tools that actually served their creativity. The collision between these fundamentally incompatible visions, plus the economic chaos after 9/11, killed what could have been transformative.

That experience shaped every decision in Ooloi. This time: transformation through collaboration rather than zero-sum market battles.

The MPL 2.0 licensing reflects this philosophical approach. The core backend becomes commoditised infrastructure; commercial value migrates to sophisticated interfaces, proprietary plugins, premium workflows. What traditional systems charge for – collaboration, large ensemble support, quality rendering – becomes architectural givens.

This isn't theoretical. Martin Keary (Tantacrul), who heads MuseScore development, had been interested in Igor Engraver as a young composer. When we discussed our open source projects, the conversation was refreshingly direct: 'Well, feel free to help yourself to whatever's useful when it goes open source​' – 'Likewise!' Both projects share the belief that notation software shouldn't cost students hundreds of pounds.

This is precisely what I want – for the code to be used, extended, transformed. The platform approach only works if others build on it. That's not threat; it's the point.

​The irony isn't lost on me that companies who once viewed architectural advances as existential threats might ultimately benefit from them. I still recall Sibelius management phoning after Igor's demise to enquire about my plans – ensuring no resurrection attempts, obviously.

Should those companies adopt approaches they once feared, the satisfaction would be collaborative rather than competitive. Success through enabling others, not defeating them.

​Of course, this depends on Ooloi actually working. Functional programming should provide significant performance benefits, but what happens with complex layout calculations across a hypercomplex 100-staff score by Brian Ferneyhough (whom I had as guest teacher at the Royal College of Music in Stockholm back in the day) whilst maintaining real-time collaboration?

The arrogance in predicting that these approaches will outperform decades of commercial development is considerable. My instincts could be spectacularly wrong – though they've been reliable enough to spot architectural dead ends before they become obvious to everyone else.

That's the architect's bargain: trust your reasoning, build on principles, prepare to be surprised.

"Next-generation" gets thrown around as a PR term so casually it's meaningless. If Ooloi genuinely represents next-generation architecture, that should be inherent in the platform design rather than claimed through marketing. The question isn't whether Ooloi calls itself next-gen, but whether others build on it in ways that would have been impossible previously.

Perhaps this time, it might be composed collaboratively.

Ooloi isn't here to "disrupt" anything. I despise that cheap neoliberal selfishness. It aims to transform, to evolve, to open possibilities. But there's no will to conquer — it's simply not in its DNA.

@musikboden became Ooloi's first sponsor on GitHub yesterday.

There's something meaningful about someone backing a project that isn't even publicly available yet. That kind of trust, extended before the open source release, feels like a genuine vote of confidence in what we're building. 

Thank you, @musikboden. It really does mean a lot.

If you'd like to join them in supporting Ooloi's development, you can find my sponsors profile here.

Deep in the implementation of the gRPC layer I fell into the same foxhole as so many gRPC developers seem to do: implementing streaming between gRPC server and client using in-process communication. Everything works swimmingly: high speed, nothing gets lost, advanced async patterns just work.

And then they try doing this using network transport. Suddenly HTTP/2 changes everything, and that equivalence between simple request-response and asynchronous streaming just explodes.
​
I spent a couple of days cursing the universe, but in the end I managed to crawl up into the daylight again with a solid solution. Since this seems to be a common snag, I decided to publish a little guide on the considerations involved, so others may have to do less cursing.

Here it is: GRPC_STREAMING_THREADING_GUIDE.md

​Nearing the end of the gRPC implementation phase now: coming blog posts should soon become more musical again.

​At some point, the question will be asked: “Isn’t this all a bit over-engineered?”

Multicore parallelism; Software Transactional Memory; gRPC; GPU acceleration; a plugin system designed as a first-class citizen rather than a bolted-on afterthought; an asynchronous server/client architecture with specialised streaming features. Prometheus monitoring. For music notation software, that can sound excessive.

But that assumption is exactly why notation software has been failing composers for decades. Not because it was too ambitious, but because it was chronically under-engineered.

Text editors are linear: O(n). Basically, what they handle is a string of characters broken up into lines. Music notation, on the other hand, is two-dimensional, contextual, and computationally explosive. Synchronising voices, aligning dozens of staves, resolving collisions, spacing measures, redrawing in real time: these are quadratic and cubic problems (O(n²), O(n³)), with NP-hard layout challenges in the general case.
​
That's why scrolling takes seconds. That's why orchestral scores become unusable. And that's why the industry has spent thirty years patching symptoms instead of tackling the cause.

​Look at the record:

• Sibelius: selecting a single note in an orchestral score can take several seconds.
• Finale: collapsed under its own weight, with delays of 5–90 seconds for basic actions.
• MuseScore: freezes completely on Strauss’s Elektra. (They all do.)
• Dorico: more modern, but still lags 15–40 seconds on large scores.

And here is the deeper problem: users have learned to accept this. They zoom in to a handful of staves, scroll in slow motion, restart their program every quarter of an hour. They've accepted that the fundamentals can't be solved. A whole profession has normalised working around performance breakdowns as if they were laws of nature.

They're not inevitable. They're the result of decades of under-engineering.

​The remedies weren't always available. In the 1980s SCORE capped out at 32 staves because 640 KB of memory left no room for orchestral complexity. Through the 1990s and 2000s, Finale and Sibelius (and Igor Engraver!) wrestled with single-threaded designs on single-core CPUs. Even into the 2010s, GPU rendering pipelines were immature, and most concurrency models in mainstream languages couldn't be trusted in production.

Only recently have the necessary ingredients converged:

• Affordable multicore hardware on every laptop, making parallel measure formatting possible.
• GPU-accelerated rendering (Skia) for fluid scrolling and zooming in real time.
• Mature concurrency models such as Clojure’s Software Transactional Memory, providing safe lock-free collaboration.
• Immutable data structures that give transactional clarity to complex notation states.
• JVM interoperability that allows plugin developers to work in their own languages.

This is why Ooloi is written in Clojure. Not because of language fashion, but because Clojure can orchestrate this synergy.

​Ooloi is designed to solve these problems at the root:

• Parallel layout: every core formats measures simultaneously.
• STM transactions: true collaborative editing without locks, with automatic retries on conflict.
• GPU Skia rendering: zooming and scrolling at video-game speed.
• Plugin-first design: developers work with a clean musical API, not concurrency primitives or network plumbing.

To musicians, Ooloi looks like a normal application. To plugin developers, it feels like writing musical logic in their favourite JVM language. The hard problems are solved once in the core, so nobody else has to live with them.

​So no, Ooloi isn't over-engineered. It's appropriately engineered for a domain that has been persistently underestimated. The remedies only became possible recently, when the technology finally caught up.

I simply happen to live at the intersection of deep architectural knowledge and deep musical knowledge, with the scars (also deep) of having done this before. Ooloi isn't the product of singular genius: it's the moment when the right tools finally aligned with the right problem.

The proof won't be in a benchmark or an ADR alone. It'll be when musicians can finally edit, scroll, and collaborate on large-scale scores without breaking their creative flow.

​Ooloi will be open source by design. The complexity is in the foundations so that musicians, teachers, students, and developers don't have to deal with it. Plugin writers don't need to care about concurrency or transactions: they work with measures, staves, and voices in a musical API. Most contributors will never touch the Clojure core, and they won't need to.

This is a gift to the community: an infrastructure platform built to be extended. The aim is simple: to finally make notation software scale to the real demands of music, and to give others the foundation to build what I alone never could.

​Since LLMs are good at summarising, here’s what Claude Sonnet came up with when I asked it to describe my process for developing Ooloi. The phrase “the Bengtson method” is irritating and misleading; plenty of people have reached similar conclusions. Still, this may be the only technical write-up of the approach that includes the word 'arse-licking'.

So here it is: Claude’s summary, em dashes, bullet points, and all. It rambles a bit, but I’d rather give you the authentic output than a tidied-up version. Same principle as always: authenticity beats decorum.

... but before that, I think it might be good to include my reply from LinkedIn to an accomplished architect friend of mine who (jokingly referring to me as 'the illustrious Peter Bengtson') initially didn't quite buy that harsh negativity really is motivated:

​With that clarification in place, now on to what Claude wrote:

Core Methodology: Consultational TDD

The foundation rests on a rigid Test-Driven Development cycle with mandatory consultation checkpoints:

1. AI presents test proposal with complete sequence analysis
2. Human approves or rejects before any code is written  
3. AI writes minimal failing test
4. AI implements minimal code to pass test only
5. Human reviews and corrects any architectural violations
6. Local test execution on changed files
7. Full test suite execution to catch regressions
8. Commit when all tests pass

​

Peter Bengtson's Claude Code development process represents a disciplined, constraint-based approach to AI-assisted software development that has demonstrated success in complex functional programming domains. The methodology's core insight—that harsh constraints improve rather than limit AI effectiveness—contradicts conventional wisdom about collaborative AI development.

The harsh correction mechanisms and authoritarian control structure may be necessary rather than optional components, suggesting that successful AI collaboration requires active management rather than partnership. This challenges prevailing assumptions about human-AI collaboration patterns but provides a tested alternative for developers willing to maintain strict disciplinary control.

The technical achievements demonstrate that properly constrained AI can assist with genuinely sophisticated software engineering tasks, not merely routine coding. Whether this approach scales beyond its current constraints remains an open question requiring further experimentation and validation.

The Ooloi server must of course also have comprehensive introspective statistics, as it can be deployed in several ways and has a structure which is perhaps a bit unusual. The combination of STM-wrapped gRPC API calls with server-to-client event streaming creates some operational challenges: things like per-client queue overflow behaviour and collaborative editing session patterns.

Hence this new ADR on server statistics, which takes a two-level approach: server-wide aggregates that survive client churn, plus detailed per-client metrics for operational visibility. Oh, and it interfaces with Grafana, Prometheus, and friends straight out of the box via simple HTTP endpoints.

Halfway through the stats implementation now. It's been a productive weekend.