OOLOI.ORG
Menu

OOLOI

An Organism Evolved.

OVERVIEW

DOCUMENTATION

NEWSLETTER

Nessun Dorma

13/8/2026

5 Comments

 
Picture
​The last post said that before closing the Piece Window I'd go through the dozen or so tickets raised in passing, and that I was enjoying it enormously. The second half held. The first half was wrong about what the list was.

It looked like a collection of unrelated small wrongnesses. It was one thing wearing a dozen hats, and the thing is this: a program can fail without telling anyone.

When something goes wrong inside a running program, the fact of it has to travel somewhere: to a message, to a log file, or at minimum to a crash, which is unpleasant but honest. Sometimes it travels nowhere. A piece of the machinery quietly stops doing its job, nothing appears on screen, nothing is written down, and the program does less than it was asked. You find out weeks later, when a file you were sure you'd saved isn't there, and there's no record of why.

Ooloi had some of these. Not many, and that's the interesting part rather than a mitigation. There are 26,048 tests, nearly two lines of test code for every line of the program itself, and not one of them had found a single instance. They couldn't have. A test checks an outcome, and these failures produce no outcome: no wrong value, no crash, nothing different for the test to look at. The suite was thorough on everything within its reach, and this was the category outside it.

Most programs never go looking for that category at all, so I should be plain about it: what follows describes a standard very few applications are held to, including large and successful ones I use every day.

So I went looking. The question the work ended on concerns absence rather than discovery: can a single failure, anywhere, permanently switch off part of the running program? Every long-lived mechanism in Ooloi was examined individually against it. None can. Three could when the work began.

What a program is doing when it waits

Alongside that ran something subtler, and it's the finding I'd keep if I could keep only one. Nowhere in Ooloi, in the program or in the tests, does anything sleep for a moment and then look to see whether what it was waiting for has happened.

Developers will know what that sentence costs. Everyone else deserves to know why it matters.

Waiting is unavoidable in software: for a file to finish being written, for a window to appear, for another machine to answer. The question is how you learn that it's done. You can sleep briefly and check again, which is a guess wearing a wait's clothes, or you can arrange to be woken the instant it happens. The guess is very nearly always good enough, which is precisely why it's everywhere in this industry. Nothing goes wrong that anybody can observe, and the tests pass, because the thing does eventually happen.

Very nearly always. A sleep is calibrated on the machine it was written on, and it holds until that machine is slower, or busier, or the network hesitates. Then the program does things out of order, and the failure looks like nothing in particular. These are the bugs that can't be reproduced, that only ever happen on somebody else's computer, and that get closed as unrepeatable.

So every wait in Ooloi is now woken by the thing it's waiting for. Time limits survive as a backstop against something never happening at all, rather than as the means of noticing that it has.

The standard a run is now held to is that green means green: nothing in the log that nobody has accounted for, and no work quietly abandoned.

​Why this doesn't usually happen

Silent failure is invisible by definition, so it never reaches a roadmap; nobody has ever filed a ticket for a bug they couldn't observe. Meanwhile there's always a release date, always a feature promised this quarter, and this work has nothing to show on the day it's finished. It's the first thing cut and the last thing missed. Under those conditions the rational choice is to ship, every time, and the debt accrues to nobody in particular until it has accrued to everybody.

What's unusual about Ooloi's situation isn't method or talent; it's the absence of the pressure that normally forbids this work, and the presence of time. Time is the actual resource here, and I have it.

Two groups benefit. Musicians get a program that doesn't lose things quietly, which I'll come to. And anyone who works on Ooloi later inherits a codebase where a green run is evidence rather than reassurance. Every hour spent chasing a bug that won't reproduce is an hour not spent on beams and slurs, and the number of those hours is decided now, by whether the foundation admits that class of bug at all. Ooloi is open source and the whole development apparatus goes public with the source, so this is the one kind of generosity I can practise in advance, towards people I haven't met.

It also can't be added afterwards. Every feature built on a silent path inherits it, and once a hundred features have inherited it, the silence is load-bearing.

What it means if you use the program

​Very little of this is visible, which is the point of it.

When Ooloi fails, it tells you what failed rather than that something did. A save that doesn't happen names its reason: the file has moved since you last saved it, the folder isn't yours to write to, the disc refused the write. Not 'an unexpected error occurred', a sentence that's never helped anybody.

And underneath that, the property it rests on: no part of Ooloi can quietly stop working while the rest carries on looking normal. A window won't open blank and fill in only after you've closed and reopened it. A change won't fail to reach the other person in a session while your screen shows it went through. The bookkeeping that lets a piece be found again won't stop being written without a word.

For a program you sit inside for eight hours preparing a set of parts, that isn't tidiness. 'It didn't save' becomes an answerable question instead of a shrug. Notation work carries a low-grade anxiety about whether the tool is a reliable participant in what you're doing, and every engraver I know has built rituals against it: saving obsessively, keeping numbered copies, never entirely trusting a session. I'd like Ooloi not to need those rituals.

PictureIn da AI Lederhosn
​Oh, and I went to Austria for the first time in my life, for a wedding, and came home with my own origins sorted out. They'd always been fogged: Italian traces, German ones, Austrian, Czech, and no account of how any of them were supposed to fit together. It turns out that my mother's side is entirely Tyrolean, which explains ... everything. South Tyrol speaks German and belongs to Italy, the Habsburgs held Bohemia, and the borders moved rather more than the Dallabrida family did. Decades of vagueness resolved in an afternoon, down to my maternal grandfather's death at Verdun in 1944, at thirty-four. Surprisingly emotional, and so, unexpectedly, was the caraway in that Schweinsbraten. Childhood and present merged.

And Vienna was of course great. But no Alban Berg museum? Wirklich??

5 Comments
Magnus Johansson
14/8/2026 18:04:15

Very, very welcome home, Mr. Bengtson! A quick search on the internet for Hedy Dallabrida gives that she was born in Chomutov, Czechia that was then known av Komotau in Germany. Is that correct?

Reply
Peter Bengtson
15/8/2026 11:55:35

Thank you, Magnus, and yes: Komotau it is. You've also landed squarely on the thing my family never managed to explain to itself.

The name is Trentino, from the valleys south of the Brenner, and there's still a house in the family in Bolzano. But my grandfather was born in 1909 in Nenzing, a village in Vorarlberg, which is where it comes apart and then goes back together. The Dallabridas had come north a generation or two earlier, along with a good many other Trentino families; whether for the mills or the tunnels I don't yet know, and the parish register will say.

The rest follows from being Austrian. Austrian in 1909 meant German in 1938, and German in 1938 meant conscription, a posting into the newly annexed Sudetenland where my mother was born, and Verdun in April 1944, at thirty-four.

She never knew why she'd been born where she was. She simply had been, and the one person who could have told her was dead before she could ask. Decades of fog, thinned by a wedding in Austria and a remark from my friend Ambros about the Vorarlberg textile trade.

The caraway, at any rate, travelled intact. Recherche du temps perdu, with Sauerkraut.

Reply
Magnus Johansson
16/8/2026 07:50:49

What happened to little three year old Hedy after her father's death in 1944?

Reply
Peter Bengtson
16/8/2026 10:17:13

That's a long story, Magnus, and one for another time. Thank you for pulling on the thread, though; it got further in two days than it had in fifty years, and there's a lot to digest.

Magnus Johansson
16/8/2026 10:24:46

"That's a long story, Magnus, and one for another time. Thank you for pulling on the thread, though; it got further in two days than it had in fifty years, and there's a lot to digest. "

OK, I see, and you're welcome. Family history is very interesting. I hope to hear the long story of Hedy sometime.

Reply



Leave a Reply.

    Author

    Peter Bengtson –
    Cloud architect, Clojure advocate, concert organist, opera composer. Craft over commodity. Still windsurfing through parentheses.

    Search

    Archives

    August 2026
    July 2026
    June 2026
    May 2026
    April 2026
    March 2026
    February 2026
    January 2026
    December 2025
    November 2025
    October 2025
    September 2025
    August 2025
    July 2025
    June 2025
    April 2025
    March 2025
    September 2024
    August 2024
    July 2024

    Categories

    All
    Accidentals
    Alfred Korzybski
    Architecture
    Backend
    Beaming
    Benchmarks
    Clefs
    Clojure
    CLOS
    Common Lisp
    DDD
    Death Of Igor Engraver
    Documentation
    Donald E Knuth
    Dorico
    Dynamic Programming
    Finale
    Fonts
    FrankenScore
    Franz Kafka
    Frontend
    Functional Programming
    Generative AI
    GRPC
    Igor Engraver
    Ingmar Bergman
    Instruments
    Jacques Derrida
    JVM
    License
    LilyPond
    Lisp
    Localisation
    MIDI
    MPL 2.0
    MuseScore
    MusicXML
    Ooloi
    Ortography
    Pitches
    Platforms
    Playback
    Plugins
    Python
    QuickDraw GX
    Rendering
    Rhythm
    Rich Hickey
    Road Map
    Scheme
    Semiotics
    Sibelius
    Silicon Valley
    Site
    Skia
    Sponsorship
    Transposition
    UI
    Umberto Eco
    Vertigo
    VST/AU
    Wednesday Addams

    RSS Feed

Home
​Overview
Documentation
About
Contact
Newsletter
Ooloi is an open-source desktop music notation system for musicians who need stable, precise engraving and the freedom to notate complex music without workarounds. Scores and parts are handled consistently, remain responsive at scale, and support collaborative work without semantic compromise. They are not tied to proprietary formats or licensing.
​
Ooloi is currently under development. No release date has been announced.


  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Technical Comparison
  • Documentation
  • About
  • Contact
  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Technical Comparison
  • Documentation
  • About
  • Contact