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.