|
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."
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.
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.
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).
Reply
Peter Bengtson
2/8/2026 09:30:12
No apology needed; the question isn't really answered above.
Reply
Leave a Reply. |
AuthorPeter Bengtson – SearchArchives
August 2026
Categories
All
|
|
|
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.
|
RSS Feed