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

I've just published ADR-0024 and, based on it, a new gRPC Communication Guide documenting when flow control helps and when it interferes.

The decision was straightforward once the analysis was done: implement flow control for event streaming (where slow clients can block fast ones) but avoid it entirely for API requests (where gRPC's threading model and STM transactions already coordinate beautifully).

Sometimes the most sophisticated solution is knowing where not to add sophistication.

The guide covers the technical reasoning and includes practical examples for anyone implementing gRPC clients, regardless of language choice.

Every community has its breaking point. Mine came on Clojurians when I wrote a single sentence:

'Clj-kondo can go away – I have 18,000 tests'.

That was enough to get my post deleted. Before the deletion, there was 'discussion' – if you can call it that. I was told my statement was nothing more than click bait.

The irony? The author of clj-kondo himself agreed with me.

What That Line Meant

It wasn't click bait. It was a statement of principle:

• Tests prove correctness. They're executable, falsifiable, and domain-driven.
• Linters and static analysis don't. They enforce style, not truth.
• Dynamic dispatch makes static analysis less meaningful. Ooloi's architecture relies heavily on Methodical multimethods and polymorphism throughout. Static analysis tools can't trace through runtime polymorphic calls, making their warnings less informative than executable tests that actually exercise these dynamic paths.
• When you've got 18,000 tests running clean, you don't need a priesthood of external validators telling you your code is 'unsafe'.

And I was careful to make the distinction explicit: clj-kondo is a beloved, useful tool. For most projects it adds value. It just happens to be of limited use in my project, because Ooloi's architecture is already validated at a different scale.

That nuance – acknowledging the tool's value whilst drawing boundaries around its relevance – should have been the beginning of a sober technical discussion. Instead, it was treated as provocation. The fairness itself was read as heresy.

The Culture Clash

The moderator (a 'Veteran Architect') didn't engage with the point. He reacted from the gut: pearl-clutching, dismissing, and finally deleting. Exactly the kind of gatekeeping I dissected in my article on functional programming gatekeeping.

And let me be clear: I have nothing against the Clojurians themselves. They're a knowledgeable, interested lot, often deeply engaged in technical detail. The problem isn't the community – it's the moderation culture.

The moderators behave more like a church council than facilitators of discussion. Their first instinct isn't to sharpen an argument, but to protect orthodoxy, maintain decorum, and suppress anything unsettling.

The ideal they enforce seems to be some kind of cold, robotic detachment – the lab-coat fantasy of neutrality – or perhaps the modern American obsession with never offending anyone, no matter how bloodless the discourse becomes. Either way, it enforces sterility, not clarity.

You can critique syntax sugar all day long, but question a community darling like clj-kondo – even whilst calling it useful and respected – and suddenly you're accused of trolling.

Why I Left

I didn't leave because I was offended. I left because I refuse to participate in a space allergic to honesty. If a community sees a blunt critique and immediately cries click bait – ignoring both the nuance of my post and the fact that the tool's own author agreed – it has no business in my world.

Ooloi is built on clarity, not ceremony. It's an architecture tested by 18,000 executable truths, not validated by a linter's opinion. If that treads on toes, good. Prissy people afraid of dark humour or communication nuances that wouldn't pass muster at a parish council don't belong in this project. And the same thing goes for hypocrites who say, 'We're inclusive here - as long as you're exactly like us'.

The Broader Lesson

Communities often confuse politeness for health. But real progress requires the courage to tolerate discomfort. If you need your software conversations padded with pillows, you'll never survive the weight of real architecture.

As Wednesday Addams would remind us: hypocrisy is uglier than bluntness, and dishonesty is far more offensive than a glass of gin before noon. Or, indeed, a well-placed 'fuck you'.

So I deleted my Clojurians account. Because sometimes subtraction is progress.

There's a moment in every software project when you realise you've been approaching a problem entirely backwards. For Ooloi, that moment came whilst implementing the frontend gRPC client. What I'd anticipated would be a tedious exercise in data transformation and type marshalling turned out to be something rather more straightforward: we could simply share the models themselves.

Most applications suffer from what I've come to think of as 'linguistic impedance mismatch': the same business concept gets expressed differently in TypeScript interfaces, JSON schemas, database models, and API contracts. Each translation introduces potential for drift, bugs, and the sort of maintenance headaches that make senior developers reach for the gin before lunch.

The Usual Compromises

When I began implementing Ooloi's frontend, I expected to follow the well-trodden path of recreating backend data models for the client, probably with a good deal of manual conversion between Clojure's rich data types and whatever could survive the journey through gRPC.

A Simpler Path Forward

But then something rather straightforward happened. Our unified gRPC architecture, built around a custom OoloiValue message format, was preserving not just the data but the semantic fidelity of Clojure structures. Ratios remained ratios. Keywords stayed keywords. Nested collections maintained their exact shape and type information.

The implications were rather obvious once I thought about it: if the data was surviving the round trip with perfect fidelity, the code could make the same journey. The broader lesson here applies beyond Clojure: when your serialisation layer preserves semantic fidelity, you can often eliminate entire categories of translation logic.

Shared Models in Practice

What we ended up with is shared model contracts across distributed systems. Not just shared schemas or interface definitions, but shared implementation: the same defrecord structures, the same predicates, the same multimethod dispatch logic working identically in frontend and backend.

For example, here's client code that uses the exact same model logic as the server:

​This isn't just syntactic sugar. The frontend literally cannot represent a state that the backend would reject, because they're using identical validation logic. Entire categories of bugs, the sort that usually emerge only in production when client and server expectations diverge, simply cannot exist.

For an open source project like Ooloi, this architectural decision has profound implications for contributor experience. New developers don't need to learn separate model definitions for frontend and backend. The cognitive load of understanding the system drops considerably when there's only one way to represent musical structures, regardless of which part of the codebase you're working in.

Architecture in Practice

What started as a practical decision to move some data models has led to a clearer architectural arrangement:

• The Shared Project contains the entire Ooloi engine: all domain models, interfaces, predicates, traits, and core business logic. This is where musical knowledge lives.
• The Backend Project is essentially a server wrapper: a thin layer that exposes the shared engine through gRPC, handles persistence, and manages component lifecycle.
• The Frontend Project is a UI wrapper: JavaFX components, user interaction handling, visual rendering.

Both frontend and backend have become lightweight adapters around a shared core, rather than independent systems that happen to communicate.

For those interested in the technical details, the complete architectural decision record is available in our ADR-0023: Shared Model Contracts.

Why This Approach Is Uncommon

Most teams face barriers that make shared models impractical: different programming languages between frontend and backend, runtime environment constraints, the natural tendency for teams to optimise for their specific context rather than maintaining shared abstractions.

We've managed to sidestep these issues through a combination of technological choices (Clojure everywhere, gRPC with custom serialisation) and architectural discipline (resisting the urge to optimise locally at the expense of global coherence). For open source projects, this consistency becomes particularly valuable: contributors can focus on domain logic rather than navigating translation layers between different parts of the system.

What This Means for Multi-Language Support

Importantly, this shared model architecture doesn't create barriers for non-Clojure clients. Python, JavaScript, or WebAssembly clients continue to work through the standard gRPC interface, using generated protobuf classes and standard API patterns. The shared models represent a Clojure-specific enhancement layer that sits atop the universal gRPC interface rather than replacing it.

Think of it as offering two levels of integration: the universal protobuf API that any language can consume, and the native Clojure API that provides richer semantics for those who can take advantage of it.

Alternative Frontend Approaches

This architecture actually makes it easier for others to build alternative frontends. Someone wanting to create a React-based web interface or a WebAssembly client has a clearly defined gRPC API to work against, with well-documented behaviour established through our shared contracts. They'd handle their own data model representations (the normal situation for any gRPC client) whilst benefiting from a well-defined backend.

We're not digging a moat here. Alternative approaches remain viable whilst the shared contracts make the Clojure experience particularly seamless.

The Broader Picture

There's something here that extends beyond the specific technical details of Ooloi. We've found that perfect type fidelity across network boundaries, combined with clear thinking about what constitutes core business logic versus infrastructure concerns, can enable patterns that many teams dismiss as impractical.

This doesn't mean every project should adopt this approach. The organisational and technical discipline required is considerable. But for projects where the complexity is justified (particularly open source projects where reducing cognitive load for contributors is crucial) the benefits are substantial.

Looking Forward

Going forward developing Ooloi's frontend, the shared model contracts have become foundational to how we think about the system. Features that might have required careful coordination between teams now flow naturally from shared understanding. The system has become more coherent and, importantly for an open source project, more approachable for new contributors.

The surprise wasn't that shared models worked; it was how much friction simply disappeared once we stopped duplicating concepts. Sometimes architectural progress comes not through invention, but through subtraction. Shared model contracts weren't a goal we set out to achieve. They emerged from following our technical choices to their logical conclusion and having the discipline not to complicate what worked.

I've had numerous requests over the years to publicly tell the story about how and why NoteHeads, the company I founded to develop Igor Engraver, collapsed in the early 2000s. I've never done so as it never was that important, but now, with Ooloi on the horizon (however it's going to turn out) it's crucial that it isn't perceived a revenge project. It's not; it's simply closure in Clojure. With interest in Ooloi building, I've decided it's time to tell my side of the story. In doing so, I had to name names – an unproblematic decision as this was, after all, nearly 30 years ago. I've moved on, and I'm sure everybody else has too.

Prologue: The Auction
Picture this scene: a solicitor's office near Stockholm's Stureplan in late 2001. In one room sit Christer Sturmark – future secular humanist celebrity – and Björn Ulvaeus of ABBA fame, who never spoke, moved, or changed his facial expression during the entire process. Ice-cold pop star. In another, I sit alone, connected by crackling international phone lines to Los Angeles, where Esa-Pekka Salonen, one of the world's greatest conductors, waits to learn the fate of software he too has invested in. Salonen, in turn, has Randy Newman on the line, film composer and subsequently Oscar winner and also a share holder.

This auction represents the musical world's last desperate attempt to save work that the financial world had already written off. By the end of that surreal session, they had acquired Igor Engraver and NoteHeads Musical Expert Systems for a paltry 200,000 SEK. I received not a penny.

What followed was an instructive disaster: the systematic destruction of genuinely revolutionary music software by what can only be described as a cavalcade of ideologues, incompetents, and narcissists who fundamentally misunderstood what they had purchased.

​What We Built: Software That Thought Like Musicians
Igor Engraver, launched in 1996, was genuinely ahead of its time. Unlike conventional music notation programs that trapped users in rigid 'modes', Igor worked the way musicians actually think – like composing with pen and music paper, but with the power of computation behind it. Many aspects of its humanised MIDI playback haven't been rivalled in terms of realism to this very day.

The concept was sufficiently sophisticated to attract some of the finest programming minds available: Common Lisp developers who grasped the elegant abstractions immediately. Common Lisp wasn't common then; finding programmers who could think in its functional paradigms was difficult. But when you found them, they understood instantly what we were trying to achieve.

Professional musicians recognised the difference. Even today, in 2025, I receive occasional messages from musicians who miss Igor and wonder whether they can somehow run the now-ancient program in emulators or simulators. This isn't mere nostalgia; it's testimony to software that solved problems other programs didn't even recognise.

​Strategic Missteps: When Money Doesn't Understand Music
But ideological programmers weren't our only challenge. Feature creep, driven by investors who fundamentally misunderstood our market, began to derail our development timeline. I remember one VC board member declaring: 'Igor will be unsellable unless it has guitar tablature for pop music'.

I resisted strenuously. Igor Engraver was designed for serious composition work - the kind that attracted interest from conductors like Salonen and composers like Newman. Adding pop guitar tablature would delay our core engine whilst appealing to a completely different market segment. We risked losing our competitive advantage in professional notation to chase a crowded amateur market.

But the VC bastards persisted, and eventually prevailed. Had we stuck to the original plan, we would have delivered Igor 1.0 well before Sibelius completed their rewrite and hit the market. Instead, we found ourselves implementing features that diluted our core value proposition whilst our window of opportunity slowly closed.

This painful lesson directly influenced Ooloi's architecture years later – I designed its plugin system to integrate so tightly with the core engine that specialised features can be added without delaying or compromising the fundamental software. Those who want guitar tablature can have it; those who don't aren't forced to wait for it.

​Sources

• Magnus Johansson's testimony in Realtid: 'Noteheads customers were furious with Sturmark'

I'll admit, when I first encountered gRPC batch operations, I dismissed them as unnecessary complexity. Then I started implementing the gRPC layer and realised something remarkable: gRPC batch boundaries map perfectly onto STM transaction boundaries.

The pattern is almost embarrassingly simple: client streams a series of operations, server accumulates them, then wraps the entire batch in a single dosync. What emerges is something genuinely powerful – distributed transactions with full ACID guarantees. Multiple musicians can edit the same score simultaneously, knowing that either all their changes succeed atomically or none do. Complex operations like MusicXML imports or multi-step undo chains become naturally transactional across network boundaries.

The implications are profound: no more partial updates corrupting shared musical data, no locks preventing collaboration, no eventual consistency headaches. Just proper transactional integrity that works identically whether you're editing locally or collaborating across continents.

How many music notation programs have distributed atomic transactions across any network? And entirely without locks, and with automatic conflict resolution? None.

​Sometimes the most elegant solutions hide in features you initially think you don't need.

Right. Quick update from the development trenches.

When I completed Ooloi's backend engine in July, starting work on the frontend interface revealed the anticipated cascade of architectural requirements that needed systematic resolution first.

Here's what emerged, in order:

1. Collaborative Undo/Redo Architecture (ADR-0015)
Thinking about frontend-backend relationships immediately raised the question: how does undo/redo work in a multi-client, distributed collaborative setup? The answer required a three-tier architecture separating backend piece changes (coordinated via STM) from frontend UI changes (local to each client).

2. Universal Settings Architecture (ADR-0016)
The insight that there should be no global application settings, only per-piece settings living inside each piece, led naturally to implementing settings not just on the piece level, but across all levels of the hierarchy. Any entity – piece, musician, staff, pitch – can now have configuration attributes via a unified defsetting macro with lazy storage and automatic VPD support.

3. Component Lifecycle Management (ADR-0017)
Multi-scenario deployment demanded rock-solid system architecture using Integrant. This needed to be in a stable architectural form – wiring, lifecycle boundaries, failure modes – before setting up the actual components with proper dependency injection, partial failure handling, structured error codes, the full production suite.

4. Automated gRPC Generation (ADR-0018)
With component architecture sorted, I could tackle the actual gRPC implementation: automating API endpoint generation for native Java interop across hundreds of methods, plus bidirectional communication for real-time collaboration. Manual implementation at this scale would be architecturally impossible.

5. In-Process Transport Optimisation (ADR-0019)
Combined deployments (frontend and backend in same process) were using unnecessary network transport. Implementing automatic in-process gRPC transport delivers 98.7–99.3% latency reduction whilst preserving external monitoring capabilities.

6. TLS Infrastructure (ADR-0020)
Secure connections are essential for distributed deployments – conservatory intranets, corporate environments, cloud SaaS situations. Auto-generating certificates with full enterprise capabilities makes this transparent whilst supporting everything from development to production.

7. Authentication Architecture (ADR-0021)
Finally, distributed deployments require comprehensive authentication and authorisation. Pluggable JWT-based providers scale from anonymous sessions to enterprise LDAP integration. This is fully designed and will be implemented as deployment scenarios require.

Current Status: About 95% of the above is implemented, tested, and production-ready.

Next Steps: Finish the auto-generated gRPC Java interop interface, then create an actual frontend client of the 'Hello World' variety and ensure it runs and communicates across all deployment scenarios.

The rather encouraging discovery throughout this process was how readily the existing functional architecture accommodated these enterprise concerns. Vector Path Descriptors naturally supported universal settings. STM transactions elegantly handled collaborative undo operations. The component system absorbed authentication providers without strain. When features like collaboration or security slide cleanly into place, it's not luck – it means the architecture wanted them there. That's what sound foundations do.

Worth noting: collaboration isn't something tacked on later. It's integral to the architecture from the ground up.
​
Right. Back to the gRPC generator.