I’ve spent the past year building Ooloi, a distributed music-notation system written in Clojure. It’s not a library, but a complete platform for working with large, collaborative scores in real time. The plan is to open-source it once the core architecture stabilises.
The problem Ooloi addresses is simple to describe but technically difficult: most notation programs treat a musical score as a single mutable graph. That works for small pieces, but once you have multiple editors, nested tuplets, cross-staff connections, or thousands of simultaneous events, those models start to break down. Ooloi represents music as immutable data coordinated through STM and transducers, allowing concurrent edits and deterministic transformations without locking.
After a year of backend and shared-core development, the system now includes:
• Transducer-based temporal traversal (timewalk) for navigating musical structures with temporal precision
• STM-coordinated backend preventing race conditions during concurrent operations
• gRPC architecture with full transport parity (network / in-process)
• Component-testing macros for reliable client/server integration
• Global object caching with hash-consing — 50 000 notes serialise to 14.5 KB (≈ 0.29 bytes/note)
• 57-field statistics system with live monitoring endpoints
• Comprehensive documentation: 28 ADRs, 9 guides, 19000+ tests
The next phase moves from infrastructure to rendering: a five-stage hierarchical pipeline and an event-driven client. The long-term goal is a minimal Clojure core with an open plugin system for any JVM language.
Website: https://ooloi.org
Documentation index: Ooloi: Documentation - OOLOI.ORG
8 Likes
Some early benchmarks you might find interesting:
2 Likes
Impressive! 0.29 bytes per note seems unreal to someone used to classic protocols like MIDI. How do you see this being used - in DAWs, as a backend for Lilypond, something else?
1 Like
Thanks! Yes, it looks almost implausible until you consider what’s being stored. Ooloi’s internal model is semantic rather than graphical – every note, slur or tuplet is a pure value with shared substructure (hash-consed), so identical material isn’t duplicated. That’s what brings the density down to around 0.3 bytes per note.
That figure covers only the musical logic. The graphical layer – positions, glyphs, spacing – will roughly double it, but even then we’re still talking kilobytes for a full orchestral score.
And yes, Ooloi is a complete notation program, not just a backend. It sits in the same territory as Finale, Sibelius, Dorico and MuseScore, but is built from the ground up using functional programming techniques rather than the object-oriented C++ models that dominate existing systems. Those older architectures tend to collapse under their own mutability – they struggle to scale once scores become large or heavily nested. Ooloi’s immutable data model and transducer-based traversal eliminate that bottleneck, allowing operations that are deterministic, parallel and memory-stable.
In practice, this means it should be possible to scroll and edit even extremely dense orchestral passages without freezing or stutter – something that remains a serious limitation in all current notation programs.
It will also include full support for virtual instruments (VST/AU) and humanised playback – expressive, timing-aware performance rather than mechanical MIDI output.
There’s more detail on these areas – architecture, engraving, playback and design philosophy – on the blog: https://ooloi.org.
The current phase focuses on rendering and interaction, now that traversal and persistence are proven.
2 Likes