​When I began coding Igor Engraver around 1995, the choice of platform was straightforward. Macs were where creativity lived. Windows – clumsy, unintuitive, user-hostile – was for accountants and management consultants. I needed to escape Finale's stranglehold, and I needed the best possible foundation for professional music engraving.

That foundation was QuickDraw GX.

Apple had released something genuinely remarkable: a complete 2D graphics and typography system with sophisticated font handling, Bézier curve operations, transformation matrices, and sub-pixel anti-aliased rendering. For music notation – which is essentially complex typography with thousands of precisely positioned curves – GX was perfect. Not adequate, not sufficient: perfect.

Igor Engraver was built on QuickDraw GX from the beginning. Mac-only, by choice and by necessity. Windows didn't matter. We founded NoteHeads, shipped the software, and believed we'd eventually need to address cross-platform support. But that was a distant concern.

​AlphaMask Inc. was founded in 1999 by Mike Reed and Oliver Steele. Reed had been the tech lead on Apple's TrueType and font system. Steele had been on the QuickDraw GX development team and had led the Apple Dylan project at Apple Cambridge – the former Coral Software, where Macintosh Common Lisp originated.

The people who built QuickDraw GX had left Apple and founded a company to continue that work. When Apple made what I considered a profound mistake in abandoning GX for OS X, the GX team apparently agreed – to the point of leaving Apple entirely to focus on their superior graphics engine.

Whether I knew about Steele's Lisp background when we chose AlphaMask, I honestly cannot recall. I like to think the choice was purely on merit: AlphaMask offered GX-level capabilities in a more decoupled, portable form. It did what we needed. The fact that someone who understood both graphics and Lisp had designed the API might explain why it integrated so cleanly with our Lisp codebase, but that may simply be a pleasant historical detail rather than a decision factor.

Either way, when QuickDraw GX disappeared, I had unknowingly followed the people whose work I trusted.

​Years later, when designing Ooloi, I chose Skia as the graphics foundation. Modern, open-source, GPU-accelerated, excellent typography, sophisticated path operations, cross-platform. I chose it on technical merit, comparing it against alternatives and finding it superior.

I had no idea that Skia was founded by Mike Reed and Cary Clark – another QuickDraw GX team member – a few years after AlphaMask. Or that Google had acquired Skia in 2005 and made it the graphics engine for Chrome, Android, and Flutter. Or that billions of devices now use Skia for their rendering. Or that the internal name at Apple for Quickdraw GX was - Skia.

QuickDraw GX has had three incarnations: first as itself, then as AlphaMask, then as Skia. The same design philosophy that made GX excellent – abstract graphics model, resolution independence, professional typography – survived through each transformation. I recognised that quality in 1995, in 2000, and in 2025, without realising I was choosing the same team's work each time.

Perhaps this indicates that certain kinds of graphical excellence are simply necessary for music notation, a constant need that has persisted since the last millennium. Or perhaps I'm simply stubborn enough to arrive at the same solutions regardless of how much time passes.

​Another detail emerged from the research. AlphaMask was acquired by OpenWave around 2001–2002, and the desktop product was discontinued. OpenWave wanted the technology for mobile browsers, not for professional graphics applications. Support ended, updates ceased.

2002 was also when NoteHeads fell silent.

Whether that timing was coincidental or causal, I cannot say with certainty. Finding a replacement for AlphaMask's capabilities in 2002 would have been extraordinarily difficult – arguably impossible. The engineering effort to rebuild on different foundations would have been substantial. Perhaps the ponytailed pop zombies running NoteHeads at that point gave up when the graphics engine disappeared. Perhaps they simply declined to invest in solving the problem. I don't know if we'll ever have a definitive answer, and frankly, the question is less interesting than the pattern it reveals.

​The reassuring aspect of this circle is that it cannot break the same way again.

Skia powers the rendering in Chrome, Android, Flutter, and countless other applications. It has billions of users. It's open-source, BSD-licensed, maintained by Google and a broad community. Even if Google stopped development – which won't happen, as Android depends on it – the codebase is available, the expertise exists, and the user base is large enough that maintenance would continue.

Similarly, Ooloi runs on the JVM, which has multiple vendors: Oracle, Azul, Amazon, Microsoft, IBM, Red Hat, Eclipse. Battle-tested is a trite phrase, but it's accurate here. The JVM has been refined for nearly three decades across billions of deployments. It provides capabilities – proper concurrency models, cross-platform consistency, mature tooling – that enable much of Ooloi's architecture.

Everything Ooloi depends upon is either open-source with massive adoption or has redundant commercial vendors ensuring longevity. This isn't accidental. This is architectural design informed by what happens when foundations disappear.

Looking back across thirty years, there appears to be a unifying pattern that I wasn't consciously aware of whilst making these decisions. A consistent need for graphical and typographical excellence. A recognition of quality when it appears, regardless of who built it or where it came from. A preference for sophisticated abstractions over quick implementations.

Perhaps I've learnt something during that time about building software that endures. Or perhaps I'm simply persistent enough to keep arriving at similar solutions when faced with similar problems. The distinction might not matter.

What matters is that the circle closes. The technology that made Igor Engraver possible in 1995 has evolved, through the hands of its original creators, into the technology that makes Ooloi possible in 2025. And this time, the foundations cannot be deprecated on a whim or acquired into oblivion.

​Oh dear. Here's another quasi-philosophical blog post from the developer who still hasn't put anything on screen. You know the genre: intricate justifications for why invisible work matters, peppered with references to Victorian poets to make the whole enterprise seem less like procrastination and more like... what? Research? Vision? Architectural discipline?

I get it. A year and a half in, I want to see five lines and a treble clef. Instead, I get Swinburne and ruminations about streams. Fair enough. But something actually happened in the last few weeks that might explain why there's still nothing to look at — and more importantly, what that absence created space for.

After completing the backend infrastructure, I could have drawn the staff. Five lines, treble clef, a few notes on screen — visual feedback that would make the work feel real, tangible, moving forward. Every instinct pointed that direction. Show something. Prove it works. Keep momentum.

I chose accidentals instead.

​Why? Because after decades of building systems, you develop a sense for what needs to happen when. Not through conscious analysis, but through pattern recognition too deep to articulate. The commercial world calls this procrastination: 'Show something now. Validate with users. Iterate visibly'. But architectural intuition operates on different timescales. Sometimes the right move is to resist visibility until foundations are provably correct.

I felt compelled — and I mean that seriously, as in compelled — to solve accidental calculation before implementing rendering. Not for rational reasons I could enumerate in a planning document, but because something about the architecture whispered that accidentals would either validate everything or expose problems that couldn't be patched later.

Scary stuff, that. Betting 18 months of invisible work on a hunch.

​If you're not a musician, accidentals are the sharps, flats, and naturals that modify pitches within a measure. Simple enough in principle: once you write a sharp on a note, subsequent notes at that pitch remain sharp until cancelled or the measure ends.

​In practice, however, it's fiendishly complex.

Every notation program faces having to handle this complexity. Most handle it through special cases, heuristics, and lots of user-facing options for 'accidental behaviour in situation X'. The complexity emerges not from incompetent developers — the best commercial systems are built by brilliant people — but from architectural constraints where mutable state and rendering-first design make comprehensive solutions intractable.

I wanted to know if Ooloi's architecture could do better. Not through cleverness, but through correctness. If you find the word 'correctness' problematic, as in 'hyper-focused proto-Aspie obsession', bear with me for a paragraph or two so I can explain.

​Swinburne's metaphor turns out to be architecturally precise. The 'languid exuberant stream' operates on two dimensions simultaneously.

There's the mechanical dimension: Ooloi's timewalker is exuberant, powerful, a computational firehose processing enormous amounts of musical data. The machinery underneath is doing extraordinary work — coordinating temporal sequences, managing state across hierarchies, maintaining correctness through thousands of simultaneous operations.

And there's the conceptual dimension: languid, unhurried, effortless. When I actually write code, I'm asking simple questions: 'Does this note's accidental equal what we remember at this pitch and octave?' No wrestling with complexity, no thinking about coordination, no managing the machinery. Just natural musical questions that flow without effort.

The division is absolute. The architecture provides the exuberant power. I provide the languid purpose. They meet somewhere in the middle, and problems that should be hard simply... aren't.

​Commercial development forecloses this path. When visual pressure exists, you cannot separate these dimensions. You're forced to think about rendering whilst solving semantics, to optimise display whilst establishing correctness, to show something whilst building everything.

The result isn't wrong exactly — it's approximate. When architecture makes comprehensive solutions intractable, you end up with many options that tune approximations. The settings don't control behaviour; they compensate for architectural constraints.

This isn't criticism of commercial developers. They're working under pressure that makes this separation structurally impossible. Ship something. Show progress. Iterate based on user feedback. Entirely rational within commercial constraints; completely incompatible with certain architectural possibilities.

Working 'in the dark' created space for pure separation. The semantic foundation could reach mathematical correctness without visual compromise. When those dimensions finally unite, capabilities emerge that mixed approaches cannot achieve.

Not different in degree. Different in kind.

​The real achievement isn't solving accidentals. It's proving that separation of concerns works. That languid conceptual flow on exuberant mechanical power enables solutions that mixed approaches cannot reach. That working in the dark creates space for architectural correctness that commercial pressure forecloses.

The accidentals solution is evidence, but he architecture is the achievement.

The stream is languid and exuberant simultaneously. The mechanical power flows abundantly underneath. The conceptual purpose moves effortlessly above. They meet where music becomes mathematics and mathematics becomes music, and problems that should be hard turn out not to exist at all.

Because the architecture is right.

And now I can begin to trust it in earnest.

​I'm re-reading Gardner Read's Music Notation from 1974. I bought my copy in 1977, which makes me 16 at the time – old enough to take it seriously, young enough to believe comprehensive understanding was achievable through diligent study. Later, this book would influence Igor Engraver's formatting decisions, though not always in ways I'd care to defend today.

What strikes me now is what Read doesn't cover. There's nothing about ledger line thicknesses, actual distances in spaces between noteheads and accidentals, sit-straddle-hang rules, slur curvatures, or tie formatting. None of the engraver-level detail that Elaine Gould's Behind Bars (2011) and Ted Ross's The Art of Music Engraving & Processing (1970, but I didn't discover it until much later) document so comprehensively. Read gives you musical orthography – what symbols mean and when to use them – but not typographical execution.

​When Magnus Johansson published examples of Igor's output on NOTATIO recently, I experienced that particular species of discomfort that comes from seeing your 25-year-old work through 2025 eyes. The ledger line thicknesses were wrong. The beam slants were inconsistent. We clearly knew nothing about sit-straddle-hang.

So what made Igor well-received? Not typographical perfection, that's certain.

First, integrated parts. Only Composer's Mosaic had them at the time, and Igor had them long before Finale or Sibelius. This alone solved a workflow problem that cost professional copyists days of manual labour.

Second, the user experience didn't fight the music. After spending years with Finale on The Maids – full score, parts, piano reduction – I ended up hating Finale. I've called it 'as user-friendly as a cactus' more than once. Creating something that didn't actively work against the creative process was evidently a sufficient innovation.

Third, note entry was fast and powerful. The modal Flow Mode interface that would later vanish completely from notation software for 23 years gave professional users substantial note entry and editing speed improvements. When you're saving many hours per score, you'll forgive a few ledger lines being slightly too thin – and there was a setting for that anyway.

Fourth, we had stellar MIDI playback and a semantic model that made things consistent rather than a collection of rules-of-thumb. That alone provided predictability. And everything could be adjusted – the absence of automatic sit-straddle-hang rules just meant more manual interventions.

The landscape in 1996 made these trade-offs reasonable. The streamlined experience outweighed what we today immediately see was missing.

​2025 is not 1996.

The leading programs have improved considerably since 1996. They're genuinely competent at beam placement and formatting – not flawless, but competent enough that egregious errors are rare.

A new program entering this landscape must get the foundations correct from day one. Beam placement, slurs, ties, accidental positioning – these must be flawless, not 'good enough to ship'. The field has progressed, and users' baseline expectations have risen accordingly.

This is as it should be. But there's something deeper that hasn't been solved.

Here's what I've stated repeatedly: Ooloi is not about 'disruption' or market share. The entire motivation is to escape what commercialism leads to and create something modern, scalable, and architecturally correct from the ground up. Why? Because music notation is an extremely messy and difficult field of computation, and it requires correctness to address its long-standing problems of scalability and accuracy.

This starts with internal representation.

The old programs – and many modern ones still in broad use – were all based on a paradigm inherited from MIDI. MIDI was the standard for pitch representation at the time, and all notation software needed MIDI output for playback anyway. This meant pitches were MIDI numbers (0-127) with attachments indicating whether they were sharp or flat. Figuring out musical context – for instance, to determine what accidentals to draw – had to be derived from something with no connection to musical structure whatsoever. It had to be inferred from context each time.
​
That's at the root of the problems programs still have with accidentals. The internal representation is designed around the presentation – the visual aspect – not around the meaning, the semantics, of the music.

And of course, MIDI has no concept of microtonality, which is why notation programs struggle with microtonal entry, presentation, and playback.

Furthermore, for duration, these early programs based their rhythmic representation on a raster of 480 subdivisions – ticks – of a quarter note (TPQN: Ticks Per Quarter Note). A quarter note is 480 ticks long in some arbitrary tempo, an eighth is 240, and so forth. This is the equivalent of pixels in a JPEG, which means there's a limit to what the raster can represent.

The number 480 isn't evenly divisible by very many factors. This leads to all the problems we're still seeing in music notation programs. Various kinds of duct tape – rules of thumb, arbitrary rounding, tolerance spans – have to be used. When tuplets are nested, the approximation errors compound. We're still seeing the effects of this unfortunate MIDI heritage in 2025.

A MIDI-derived representation centred on presentation – the visual aspect – will always have difficulty interpreting what the music means. That interpretive layer is essential for presenting it correctly and consistently.

For that, you need a semantic model, which turns this on its head. The representation is 'musically correct' and detached from its presentation. Once this is in place, you can make informed decisions instead of relying on rounding and rules-of-thumb. It also makes things like playback trivial, which in MIDI-based systems is paradoxically complex.
​

​Igor Engraver was, I believe, one of the first programs – possibly the very first – to use a fully semantic internal model. It was also the first to model the real world by using Musicians playing Instruments, which allowed new and powerful abstractions.

It's interesting that Dorico also has this arrangement, though they call their Musicians 'Players' – but it's the same thing. I have no idea whether Daniel Spreadbury was inspired by Igor here, but it's not unlikely. On the other hand, introducing Musicians/Players into the representational hierarchy is a logical choice once you commit to semantic modelling.

I'm not certain Dorico has a fully semantic model, though it's closer than any other program I know of. LilyPond doesn't, despite its sophisticated batch nature. One telling diagnostic: look at how they handle remembered accidentals for grace notes, and how they treat them rhythmically. Another: how durations are represented. If they're floating-point numbers, they're approximations. For true accuracy in all situations, you need rational numbers – infinite precision, always correct. Anything else eventually leads to problems.

If a program has problems with edge cases or behaves inconsistently when dragging things cross-staff, check how it represents pitch and duration. If floating-point is involved, or rasters of ticks (480 or otherwise), the representation isn't semantic. The program might still handle 95% of hairy accidental placements competently. But when it starts having problems with tied notes across key changes or grace notes at measure starts, you know rules-of-thumb are involved – which means results can never be fully deterministic.

Ooloi is fully semantic with the explicit intention of making results fully deterministic.

This might not matter if you're satisfied with what capable commercial programs achieve today. That's legitimate – they handle about 95% of cases well. But if you depend on the remaining 5%, or if you spend your days as an engraver adjusting those 5% repeatedly, then you understand what I mean by deterministic results saving considerable time.

Now, on to Gould and Ross – books that weren't available when Igor was created. We'd inevitably have implemented their specifications had we had time. But as you know, I was ousted from my own company by venture capital pop zombies before we could. They thought guitar tablature was more important than correct engraver-level beaming.

This time, there will be no guitar tablature at the expense of correct beaming and orthography. All things in their proper order. Lead sheets are kid's stuff, comparatively speaking, and will be added later as plugins.

​Each stage is pure transformation. Grace notes are repositioned to exact temporal locations based on tempo-dependent duration (85ms default, compressed on collision). Simultaneities group by rhythmic position. Conflicts detect same-letter different-accidentals at the same moment. The reducer threads remembered state through the stream, accumulating decisions.

This pattern will handle dynamics, articulations, phrase marks: any notation requiring temporal context. The abstraction scales because the foundations were right to begin with.

​The algorithm produces semantic decisions about accidental requirements, independent of layout. These decisions are deterministic: same music, same decisions, always. They're layout-independent: work identically across all visual representations. They're configurable: house style settings modify behaviour without code changes. They're correct: edge cases handled through the same mechanism as common cases.

But here's what matters: I didn't design these four systems to work together. I designed each to solve its own problem correctly. The alignment emerged because correct solutions in related domains tend to compose naturally.

This is evidence. Either the domain model reflects musical reality accurately, or I've successfully imposed coherent structure on chaos. Those are different conclusions with different implications, but both suggest the foundations can carry what comes next.

​Why now? Why remembered alterations before any visualisation exists?

Because I needed to know whether the foundations were actually complete. Pitch, rhythm, key signatures, temporal traversal: individually validated, but never tested as a system. Remembered alterations forced that test. If they didn't align naturally, I'd have learned something important about what was missing.

They aligned. Beautifully. With no compromises in existing architecture, no special cases, no friction. Four systems built independently composed into a solution more elegant than any I'd planned.

That's conceptual closure. That's knowing the foundations are right before proceeding to build on them. That's why this work happened now, before technical necessity demanded it.

The next phases (windowing, rendering, note entry) will build on these same primitives. But now I know they're sound. Not because I believe they should be, but because I've seen them work together when they had no reason to unless the underlying model was correct.

The window opens soon. But first, this needed to be right. Now I know that when notes appear on screen, there will be no special cases left to fix, no rules-of-thumb to implement. Accidentals are now correct regardless of staff, voice, cross-staff, or cross-measure situation or house rule preferences.

​Es ist alles eins, as Marie sings in Wozzeck. But in a good way.

Key Signatures in Ooloi have been specified and implemented, and as a result we have a new Architectural Design Record, ADR-0034, on the Key Signature Architecture.

​​It covers standard key signatures – the usual and expected: major, minor and modal in all keys:

Key signatures with double flats or sharps are also supported:

​Ooloi also supports keyless signatures, custom key signatures mixing flats and sharps, as well as microtonal key signatures.

The ADR shows the internal architecture - what the software does behind the scenes. Users enter key signatures through standard dialogs: 'Eb major', 'D Dorian', etc. The technical infrastructure matters because it's what enables all those custom and microtonal features to work seamlessly alongside standard notation.

Fractional numerators are now official. Ooloi’s time-signature system (ADR-0033) supports everything from common time to irrational and additive meters, and now fractional counts like “2½ / 4”. Halves only, for now – enough to cover Grainger and Chávez without venturing into Boulezian fantasy.
​
Full ADR: ADR-0033-Time-Signature-Architecture

​Madeleine never existed. Igor Engraver did.

Scottie reconstructs a performance designed to deceive him. I'm reconstructing software that worked perfectly well with the technology it had. Igor Engraver didn't die from technical inadequacy. It died from narcissistic neglect by guys with ponytails who couldn't see past their own reflections.

The architecture was sound. QuickDraw GX handled what we asked of it. Common Lisp did exactly what we needed. The software worked. What failed was human commitment, not technical capability.

Ooloi takes the same architectural vision and asks: what becomes possible when you're free of narcissistic partners and have access to genuinely better tools? The answer: not survival, but fulfilment of what was always possible.

​For, which is important: unlike Scottie, I'm not reconstructing the same woman. That's another significant difference. Igor's strengths lay in its ease of use and its user interface (and its playback, but that's another matter). Ooloi must go much further than Igor ever did in terms of typographical beauty, and it must do so from the first release.

​Bernard Herrmann's score for Vertigo doesn't just accompany the psychological state; it induces it. Those falling, spiralling arpeggios. Obsessive motifs that keep returning. Chromatic harmonies that never resolve. Lush orchestration that simultaneously feels unstable.

The music is Wagner's Tristan und Isolde transformed – the same chromatic restlessness, the same endless longing, the same refusal to resolve. Wagner created music about impossible love that could never find harmonic rest. Herrmann took that DNA and made it cinematic, made it about obsession itself rather than the object of obsession.

Years ago I quoted four measures from Herrmann's Vertigo in my opera The Maids – using his music about false love to underscore Genet's performed identities. Servants performing their mistress, performing revolution, performing each other. Identity as pure theatrical construction with no stable referent.

The circularity is almost too perfect: the composer of Vertigo scoring the film about vertigo, whose music I once quoted to mark falseness, now frames my own question – whether I'm caught in the same spiral of reconstruction.

But notation software can prove itself. Ooloi either handles Strauss's Elektra without freezing or it doesn't. It either supports real-time collaboration or it doesn't. Unlike Scottie's obsession, mine has to compile.

​This has always been the question. Vertigo asks it. The Maids asks it. Every recursive project asks it.

Is Judy really Judy if she becomes Madeleine? Was Madeleine ever real? Does performed identity become real identity through sufficient commitment? Is Ooloi Igor Engraver, or am I performing the identity of my younger self while building something entirely new?

Most programmers rebuild things pragmatically – new requirements, new tools, new project. But I'm asking whether I'm still the same architect when the materials have completely changed. Whether continuity of vision across technological discontinuity constitutes identity or elaborate self-deception.

The technical choices answer the question.

I preserved the idea: architectural vision, musical semantics, core abstractions, the fundamental insight that notation software requires deeper engineering than the industry has provided. But I let the implementation transform completely: Clojure instead of Common Lisp, STM instead of locks, GPU rendering instead of QuickDraw, immutable data structures, client/server architecture.

That's what genuine identity actually is: essential persistence through necessary transformation.

​Scottie's spiral destroyed him because the object was always false. The reconstruction was doomed because there was nothing real to reconstruct.

My spiral can succeed because the architecture was always sound; what failed was human commitment, not technical possibility. Igor Engraver died from neglect, not inadequacy. The guys with ponytails moved on. I did too,  from the circumstances. But not from the subject.

Twenty-five years later, the obstacles aren't technological maturity – they're human. I can build this alone, without partners whose narcissism exceeds their commitment. I can use tools that are genuinely better (Skia, STM, cloud architecture) without needing them to justify the project's existence.

The obsession is real. The vertigo is real – that uncanny feeling when you realise what was abandoned can be completed. The psychological pattern is acknowledged. But where Scottie's reconstruction existed purely in romantic space with no objective validation, mine has material proof: code that compiles, tests that pass, collaborative editing that actually works, Strauss's Elektra rendering in real time.

Identity is architectural continuity, through material transformation and human liberation. Not performance. Not even evolution. Completion.

The spiral passes the same point, but at a different height. This time, without the ponytails and the pop zombies.

​Vertigo remains my favourite film. I understand Scottie's obsession. I recognise the danger. But I also know the difference between reconstructing what was never real and finishing what should never have been abandoned.

The partners are gone. So are the commercial pressures. The new architecture holds. Herrmann's spiral ends in unresolved ascent – motion without final cadence. Ooloi's must too.

​Time signature support in Ooloi, from common to esoteric.

Ooloi of course supports the usual:

... and in 'the usual' I include things like time signatures spanning multiple staves in scores for readability purposes, etc. You know, what you'd expect from a modern, professional program.

​Specifying a time signature is simple: you just write your signature as a string in the input dialog: "4/4", "C", "2/2", etc. As you will see, this paradigm holds for very complex or unusual meters, too.

Additive meters are of course also supported:

which simply is entered as "3+2+3/8".

which is entered as "2+2+2+3/8". You get the idea.

​You can do things like this too:

This would be input as "1/4+1/4+3/8+1/4". Use whitespace for clarity if you like: ​"1/4 + 1/4 + 3/8 + 1/4".

​You can combine this with multiple terms:

... which simply is entered as "3+2/8 + 6/16".

Carl Orff invented a notation showing beat duration as a note symbol rather than a number. It's occasionally useful, so Ooloi supports it:

or

They are entered as "3/8" and "2/4.", respectively (don't miss the full stop at the end of the second string). There's a checkbox to trigger this type of formatting – but as the second example contains a dotted value, Ooloi will detect the latter case automatically.

Boulez, Ferneyhough, Finnissy et al. Yes, Ooloi will support fractional meters such as 4/3 or 4/5. I personally would never use them, but then it's not up to me to pass judgement on what I think is musical over-engineering. That's what conservatories are for.

​Consequently, Ooloi supports the following:

​Bärenreiter, Durand, Peters, Schott, Universal Edition. Publishers whose engravers spent ten years learning how to disappear behind their craft.

The copper-plate aesthetic: bold, confident, generous. Staff lines weighty enough to guide the eye, noteheads round enough to feel sung, stems drawn with conviction.

Modern digital engraving forgot this. It grew thin, bloodless — optimised for screens instead of for musicians.

The lineage is clear, and the standard unchanging: those 1920s scores, those shortened ledger lines, that unspoken discipline that still knows how to sing.

We all worship at that shrine.

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

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

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

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

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

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

The work continues.

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

Flow Mode was straightforward. You pressed “.” once and staccato stayed active; crescendos 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.

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.