Different engines, same road
Different notation systems address the same underlying problem through different architectural approaches, shaped by the constraints of their time. The differences are not primarily about feature sets, but about internal models, constraints, and how change is handled over time.
1. Method
Ooloi is developed through explicit architectural decision-making rather than incremental feature accumulation.
Architectural Decision Records (ADRs), guides, and benchmarks document why decisions are made, what alternatives were considered, and what constraints follow. These documents are public and persistent. Releases reflect completed reasoning rather than milestone targets.
This approach prioritises correctness and coherence, with iteration occurring where those constraints permit.
2. Lineage
Music notation software has evolved through overlapping lineages, each addressing a different aspect of the same long problem.
Each system advanced the field in a specific way.
Ooloi continues within this lineage, with a semantic core, open implementation, and documentation produced alongside development.
3. Architecture as Problem Solving
Ooloi’s architecture is shaped by a small number of long-standing structural problems in music notation software that have historically been treated as heuristic or left unresolved:
Ooloi addresses these problems by treating musical structure as explicit data, enforcing invariants at the semantic level, and deferring graphical realization until all required information is available.
The result is deterministic behaviour under arbitrary change, rather than reliance on corrective or compensatory passes.
4. Consequences in Use
Because a single semantic model underlies editing, traversal, rendering, and collaboration:
These properties follow from the architecture rather than being added as separate features.
5. Evolution over Time
Ooloi is designed so that the system can evolve without invalidating existing musical data or user-level assumptions.
Open-source licensing, explicit documentation, and semantic representation make the system inspectable and maintainable beyond individual releases, organisations, or development phases, independent of stewardship.
No claim is made about outcomes.
Only about the constraints under which the system operates.
1. Method
Ooloi is developed through explicit architectural decision-making rather than incremental feature accumulation.
Architectural Decision Records (ADRs), guides, and benchmarks document why decisions are made, what alternatives were considered, and what constraints follow. These documents are public and persistent. Releases reflect completed reasoning rather than milestone targets.
This approach prioritises correctness and coherence, with iteration occurring where those constraints permit.
2. Lineage
Music notation software has evolved through overlapping lineages, each addressing a different aspect of the same long problem.
- Finale (1988) demonstrated that professional engraving could exist on personal computers, establishing notation as structured digital data.
- Sibelius (1993) prioritised fluency and speed of input, reshaping how musicians interact with notation software.
- LilyPond (1996) treated engraving as a typographic problem, showing that quality could be algorithmic rather than manual.
- Igor Engraver (1996–2001) modelled music semantically, structuring notation around musical meaning rather than graphical placement.
- Dorico later demonstrated that this semantic approach was viable in a commercial context.
- MuseScore (2002) made notation software widely accessible through open distribution.
Each system advanced the field in a specific way.
Ooloi continues within this lineage, with a semantic core, open implementation, and documentation produced alongside development.
3. Architecture as Problem Solving
Ooloi’s architecture is shaped by a small number of long-standing structural problems in music notation software that have historically been treated as heuristic or left unresolved:
- Conflation of musical meaning and graphical layout
- Heuristic layout and corrective passes
- Loss of determinism under change
- Implicit or approximate models of musical time
- Stateful, context-dependent notation rules
- Architecture that cannot scale semantically
Ooloi addresses these problems by treating musical structure as explicit data, enforcing invariants at the semantic level, and deferring graphical realization until all required information is available.
The result is deterministic behaviour under arbitrary change, rather than reliance on corrective or compensatory passes.
4. Consequences in Use
Because a single semantic model underlies editing, traversal, rendering, and collaboration:
- large scores remain responsive under continuous editing
- score and parts are views of the same structure
- MusicXML import and export operate on meaning rather than approximation
- collaborative editing preserves consistency without reduced expressivity
- extensions integrate through plugins without altering the core
These properties follow from the architecture rather than being added as separate features.
5. Evolution over Time
Ooloi is designed so that the system can evolve without invalidating existing musical data or user-level assumptions.
Open-source licensing, explicit documentation, and semantic representation make the system inspectable and maintainable beyond individual releases, organisations, or development phases, independent of stewardship.
No claim is made about outcomes.
Only about the constraints under which the system operates.
Next: Back to Overview