Is Ooloi Over-Engineered?

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

Why Notation is Different

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.

A History of Accepted Failure

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

Why Now?

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

What Ooloi Actually Delivers

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

Not Over-Engineered: Just Finally Engineered

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

A Platform for the Community

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