Most music notation systems maintain separate representations for editing, rendering, transport, and storage. Synchronising them is where the complexity lives and where the failures accumulate: layout-coupled mutation, heuristic correction passes, format-lossy round-trips, state that means one thing on the client and something slightly different on the server.
These are not implementation shortcomings. They are architectural consequences of decisions made decades ago — mutable scene graphs, MIDI-derived time models, presentation-first data structures — that cannot be resolved by better code within the same constraints.
Ooloi takes a different position.
Music notation is a harder computational problem than it appears. It combines multiple non-nesting hierarchies, non-local context dependencies, exact rational arithmetic, concurrent structural mutation, and constraint satisfaction under real-time interaction — with a specification defined not by a formal grammar but by a millennium of accumulated practice. Most notation software has been written by very competent engineers. The failures are not in the engineering. They are in the modelling.
These are not implementation shortcomings. They are architectural consequences of decisions made decades ago — mutable scene graphs, MIDI-derived time models, presentation-first data structures — that cannot be resolved by better code within the same constraints.
Ooloi takes a different position.
Music notation is a harder computational problem than it appears. It combines multiple non-nesting hierarchies, non-local context dependencies, exact rational arithmetic, concurrent structural mutation, and constraint satisfaction under real-time interaction — with a specification defined not by a formal grammar but by a millennium of accumulated practice. Most notation software has been written by very competent engineers. The failures are not in the engineering. They are in the modelling.
What Ooloi Is
Ooloi is a music-engraving system built on a single, authoritative work model that applies identically on the client and the server.
The same domain objects, operations, and semantics are used:
There is no separate “client API” and “server API,” no import/export boundary, and no reduced, negotiated, or translated representation when crossing the network. Musical structures are values, not session-bound or UI-owned objects, and retain their identity through the entire lifecycle.
Operations are expressed in musical terms and apply uniformly at every structural level, without context-specific reinterpretation. Addressing is value-based rather than pointer-based, which makes all operations serializable and network-safe by construction. Transactional guarantees are preserved across boundaries; atomicity and consistency are not special cases of remote operation.
The system is mathematically exact rather than heuristic by construction. Musical time is modeled explicitly. Structural rules are enforced as invariants. There is no corrective pass to tidy up what heuristics would otherwise get wrong.
This symmetry is not traded against performance. The architecture is designed around:
As a consequence of this structure, the system sustains very high operation throughput with low GC pressure, even under concurrent modification and networked use.
The same domain objects, operations, and semantics are used:
- locally and remotely,
- before, during, and after transport,
- in single-user and collaborative contexts.
There is no separate “client API” and “server API,” no import/export boundary, and no reduced, negotiated, or translated representation when crossing the network. Musical structures are values, not session-bound or UI-owned objects, and retain their identity through the entire lifecycle.
Operations are expressed in musical terms and apply uniformly at every structural level, without context-specific reinterpretation. Addressing is value-based rather than pointer-based, which makes all operations serializable and network-safe by construction. Transactional guarantees are preserved across boundaries; atomicity and consistency are not special cases of remote operation.
The system is mathematically exact rather than heuristic by construction. Musical time is modeled explicitly. Structural rules are enforced as invariants. There is no corrective pass to tidy up what heuristics would otherwise get wrong.
This symmetry is not traded against performance. The architecture is designed around:
- immutable values with structural sharing,
- push-based traversal rather than recursive descent,
- localized transactional mutation,
- and minimal allocation during traversal and editing.
As a consequence of this structure, the system sustains very high operation throughput with low GC pressure, even under concurrent modification and networked use.
What This Enables
Because identity, semantics, and operations are preserved:
What exists is not a collection of features, but a foundation: a single algebra of musical structure that remains intact across time, space, concurrency, and scale.
- A musical structure can be fetched from the server, modified locally with the full API, and written back without loss, reinterpretation, or reconciliation.
- Undo and redo are structural rather than reconstructive.
- Collaborative editing does not require semantic compromise, reduced expressivity, or simplified rules.
- Import, editing, traversal, and rendering operate on the same underlying model.
- The implementation can evolve without invalidating user-level code, stored scores, or musical meaning.
What exists is not a collection of features, but a foundation: a single algebra of musical structure that remains intact across time, space, concurrency, and scale.
The Remembered Accidentals pipeline
Next: Technical Comparison