OOLOI.ORG
Menu

OOLOI

An Organism Evolved.

OVERVIEW

DOCUMENTATION

NEWSLETTER

What Undo Remembers

21/7/2026

8 Comments

 
Picture
The anniversary post ended with a promise that the next stretch would be brighter. So here, by way of keeping it, is Verklärte Nacht.

What you're looking at is a string sextet set up in the Piece Window: two violins, two violas, two cellos, their names arriving in German from the Instrument Library, which carries its contents in many languages and supplies whatever the piece prefers. On the right, a score of six musicians and the individual parts. And above it all, the Edit menu is open, which is the actual subject of this post. Note that the undo and redo entries are named. 'Undo Change Reorder Instruments'. 'Redo Change Language filter'. The menu tells you what will happen before you press anything, and what it says is what occurs.

The Piece Window work continues, and as usual the work clarifies the road ahead. Building its full functionality meant implementing undo and redo for everything it does, and doing that forced a question into sharp focus: what, exactly, belongs in an undo chain?

The answer Ooloi gives is strict. An undo entry is a record that the piece changed, together with the means of restoring what it was. Nothing else qualifies. In particular, selections don't. Selecting a musician, a stave, a measure changes nothing about the piece; it changes something about you. A selection is a fact about a user, and it lives and dies with that user's session.

In a single-user program this distinction can be fudged, and the temptation to fudge it is real: selections feel like actions, actions feel undoable, and a naive implementation will happily record them. Collaboration removes the temptation by removing the ambiguity. In Ooloi, the undo history of a piece is shared, because the piece is shared. When you undo, you're operating on the same history I see, and the backend applies the reversal for both of us. Now imagine selections in that chain. Your Cmd+Z would unwind my mouse clicks. The history would silt up with everyone's browsing, and undoing one wrong note would mean stepping backwards through an afternoon of other people's attention. Nobody would design that on purpose. The multi-user case doesn't introduce a new rule; it makes the existing rule impossible to ignore.

And there is a recognisable failure mode on the other side of it. Record the non-events, and the chain grows long and cluttered; the honest remedy would be to stop recording them, but the tempting remedy is more interface: give the user a window onto the history itself, so they can survey the sediment and leap across it. When undo needs a map, something has gone wrong with the territory.

So Ooloi's chains stay short and truthful. Every entry is a real change to shared state, named and localised, and the same history is visible to every connected client. The host can undo a guest's edit; the reversal propagates back to the guest. That was the substance of the two-laptop proof in June, and the Piece Window has now inherited all of it.

Which brings me to the point of this progress report: with this work, the undo and redo machinery is complete across the entire application. The full design is recorded in ADR-0015, but the shape of it is simple. The backend keeps one coordinated history per shared resource, whether that's a piece or the Instrument Library. The frontend keeps a separate local history for what's genuinely local, such as appearance and panel arrangement, since your dark theme is no more a fact about the piece than your selection is. A single Cmd+Z serves both; a small router decides which history is current, and the menu always shows the answer before you commit to it.

It also holds for plugins, and this is worth dwelling on for a moment. A plugin modifies a piece through the same API as everything else, and the mutation registers its own undo step as it commits, described and localised like any native operation. Plugin authors write no undo code at all. They can't forget it, can't implement it inconsistently, and can't corrupt the shared history, because there's no surface through which any of that could be expressed. This is the house method applied once more: the wrong thing isn't forbidden, it's inexpressible.

As for the sextet on screen: two people walk through a cold night, something difficult is said plainly, and the music ends warmer than it began. As a description of implementing undo in a collaborative system, that will do.
8 Comments
Magnus Johansson
21/7/2026 14:27:16

"Note that the undo and redo entries are named. 'Undo Change Reorder Instruments'. 'Redo Change Language filter'. The menu tells you what will happen before you press anything, and what it says is what occurs."

Excellent!

Reply
Peter Bengtson
21/7/2026 15:05:33

Thanks, Magnus. The label is old craft; the guarantee behind it is the point. Every entry is a real change to the piece, and what the menu promises is what the backend does, on every connected screen.

On another note: your 'Excellent!' makes me wonder what it refers to. I know that some other programs provide detailed Undo/Redo labels (some of them later than others); you're not referring to how Igor did things? I honestly can't remember, but I really hope we labelled things properly.

Reply
Magnus Johansson
21/7/2026 17:47:28

It refers to the explicity in the menu, and Igor has the same, but Igor also has a menu item called "History" where one can select a certain point in the chain of actions to return to. Will Ooloi have that too?

Peter Bengtson
21/7/2026 18:21:28

Well, that's a relief! ;) Glad we had informative Undo labels way back when. As for your question: I have no recollection of why we put it in there; but you've used Igor more than anyone, and you're still using it, so let me turn it around: have you ever actually found the History window useful? If so, for what?

Reply
Magnus Johansson
21/7/2026 21:09:32

Yes, I have found it useful when I have wanted to return to a certain earlier stage in my work. It can also be interesting to get an overview of how I reached one or several earlier stages.

Reply
Peter Bengtson
22/7/2026 12:24:07

That's genuinely useful to know, thank you. And it fits, I think. Igor's chain contained only real changes, no selections, so its History was a list of facts about the piece: a perfectly honest thing to offer a view of. What the post pushed against was the other case, where a history browser exists to help the user wade through a chain full of non-events. A map of good territory is fine; a map that exists because the territory is unnavigable is the problem.

Your two uses are interesting because they're really two different things. Returning to an earlier stage is checkpointing, and in a collaborative setting that probably wants to be versions rather than undo-jumping, since leaping backwards through a shared chain means unwinding other people's work on every connected screen. The overview is provenance, and there a shared chain of named entries has something Igor couldn't offer: the history can say who did what. Both are worth having. Neither needs to be Cmd+Z.

Michael Edwards
2/8/2026 01:12:07

It seems that "undo" or "re-do" chains are really complicated when more than one person works on a score - something I had not hitherto really given much thought to (I'm glad that it's likely I would be the only person working on my own scores, as the mechanics of multiple people working on a score strike me as quite mind-bending).
But I must admit I don't entirely understand the foregoing exchange; obviously, Magnus is far more knowledgeable about these matters then I am.
What do you do about the situation where user A might makes a series of undos that include actions that user B did earlier, and B objects to that? Obviously A and B have to work out a solution between them, and agree on something; but how does the software handle this kind of situation? (And if the foregoing exchange covers this, I apologize, but I said I didn't entirely understand it, and so the answer I seek, if already covered, escapes me.)
I'm looking forward to trying out this new program. Is there an approximate time-frame within which it will appear?
Good luck with everything, Peter.

Reply
Peter Bengtson
2/8/2026 09:30:12

No apology needed; the question isn't really answered above.

Working alone, none of it applies to you. There's one editor, so the shared history is simply your history, and Cmd+Z behaves exactly as it does in any program you've used, naming each action in the menu before you commit to it. That isn't a special case bolted on for solo users; it falls out of the architecture.

With two or more, the aim is to prevent your scenario rather than arbitrate it afterwards. Nothing is ever silently rewritten, and each piece will carry a setting for how far anyone may reach into someone else's work: blocked, where your undo stops at the point another person last touched the piece (a teacher's score, or an editorial team with agreed domains); confirmed, where you can undo a colleague's action but are told whose it is and asked first; or open, for two people who trust each other entirely. In every case the menu names the next undo before you press anything, and if A undoes something of B's and B objects on the spot, Cmd+Shift+Z puts it back.

'To Undo or Not to Undo' (https://www.ooloi.org/home/to-undo-or-not-to-undo), from 16 May, works through the whole problem at length if you want it.

As for a time frame: no date, and there won't be one until there's something to release. What I can say is that things are accelerating. I expect to be dealing with layouts, actual sheets of music, sometime during the autumn, which means you may well be seeing notation on screen. That isn't a release date, but it is the direction of travel.

Good to hear from you again, Michael, and thank you for the good wishes. Do keep asking when something doesn't land: the question you apologised for is the one that got the clearest answer out of me.

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