Oh, dear, Magnus. Those images... None of them are fully acceptable. Igor's version is dreadful, but it's also 25 years old.
Let's look forward instead. Ooloi's version should follow proper rules a la LilyPond, from the first beta. That's the bar. Otherwise Ooloi would be dead in the water. It might not be fully feature-complete at that point, but the basic notational stuff must be flawless from the beginning.
Daniel Spreadbury wrote on the Dorico development blog at an early stage something along the lines of "Depth of implementation is far more important than breadth of features". That's exactly my approach. Because that's the only way to show that you're serious.
And I think that will decide when the first release goes public and Ooloi becomes open source: when those fundamental things are beyond reproach. And, moreover, have soul.
Last edited by PeterBengtson on 28 Oct 2025, 11:29, edited 1 time in total.
PeterBengtson wrote: 27 Oct 2025, 19:48
Oh, dear, Magnus. Those images... None of them are fully acceptable.
I agree, but I think the ledger line example from LilyPond's essay doesn't need ledger line shortening; there is room enough for a normal ledger line if one sets back the flat sign a little.
Igor Engraver 1.7 via CrossOver on Debian GNU/Linux or Q4OS.
Quite right — it’s one of those marginal cases that shows how subtle judgement can be. Personally, I love it in this example; it shows the attention to detail master engravers naturally apply, almost at the edge of perception. Ledger-line shortening isn’t a rule so much as a courtesy; sometimes it’s right, sometimes not. What matters is that there is an awareness of these things and that the software lets the engraver decide.
Last edited by PeterBengtson on 09 Nov 2025, 09:50, edited 1 time in total.
How will OOLOI handle condensed scores versus individual parts? Dorico still struggles with this.
A similar challenge appears with multi-staff divisi, especially in transitions between single-staff and multi-staff writing.
Dorico also has persistent issues with slur and tie geometry—including very short and very long slurs, cross-system slurs, slurred grace notes, and flat slurs.
In short, many engraving techniques that were standard in traditional plate engraving remain difficult or impossible to reproduce.
Condensed scores are essential but genuinely difficult. The problem isn’t just visual reduction; it’s deciding when condensation clarifies and when it obscures. Voice crossing, articulation conflicts, and readability trade-offs make it a layout rather than a drawing issue. I need to study how those decisions interact with the page-layout optimiser before fixing an approach.
Slurs and ties are among the hardest engraving problems. Good geometry depends on balancing several competing aims at once – curve shape, collision avoidance, entry and exit angles, direction, and spacing across systems or with grace notes. Each case needs different treatment.
I’m prioritising the underlying geometry system first. Slur and tie work will follow once the windowing system is complete and can support proper iteration. Condensed scores will come later still, as they depend on the page-layout system being mature enough to handle the optimisation interactions mentioned above.
That’s why I suggested using an AI engine in OOLOI. Rule-based approaches to slur placement and geometry haven’t worked well in notation software — it seems like exactly the kind of problem machine learning could solve.
Machine learning for slur and tie geometry is a reasonable suggestion. There's precedent for it in typesetting and layout optimisation.
The constraint is speed. Slur and tie placement happens in real time: every added or moved note may affect several slurs and ties at once. Any AI/ML inference step in that loop adds latency, which quickly compounds across a large score. In dense orchestral writing – the Elektra recognition scene, for instance – you might have hundreds of slurs and ties recalculating simultaneously. The arithmetic becomes unforgiving.
Rule-based geometry has the advantage of being predictable and incrementally refinable. You can reason about its cost and improve it piece by piece. Machine learning inference is harder to bound, and its performance depends heavily on hardware assumptions.
Ooloi's architecture was built precisely to avoid the pathologies that appear when notation systems meet large scores: unpredictable pauses, exponential layout cost, sluggish interaction. Making an ML engine the default slur/tie formatter would reintroduce that same overhead from another direction.
That said, nothing prevents it. The formatting and geometry systems are modular; a plugin could replace or extend the default algorithms with an ML-based approach if it proves fast and stable enough. These aren't ideological limits – they're practical ones, and they exist to keep very large music editable in real time.
