In the past weeks, I've been focused on FrankenScore's core architecture. I'm not rushing to open-source this; instead, I'm taking my time to craft a solid platform that will do the heavy lifting for future users and collaborators. All the complexities involving data representation and manipulation in a multi-threaded environment must be solved so collaborators can concentrate on the essentials. Clojure is ideal here, just as Common Lisp was the clear choice for Igor Engraver back in 1996.

Key developments:

1. The API is now fully polymorphic and can be used in the same way internally in the backend as in the frontend. There is a system of pointerless vector path descriptors (VPDs) implemented for this purpose that all API operations can accept as part of their polymorphic setup. I wouldn't be surprised if core collaborators will use the API for internal purposes as well, as it is highly efficient and exposes the underlying functionality in an abstract, domain-specific way. There should be little need to go directly to the underlying data structures, at least not for speed - and certainly not for expressivity. This also bodes well for plugin development in other languages than Clojure, which is an important feature.

2. This beast is fast. Clojure's STM facilities ensure high-speed ACID-compliant transactions with automatic retries. They are also composable. This means that plugins can bombard the backend with hundreds of thousands of mutation requests, for instance to implement MusicXML, with the same efficiency as the pure Clojure backend.

3. Piece Manager Implementation: There's now a Piece Manager, providing functions for storing, retrieving, and resolving pieces from IDs. This allows for multiple clients to work simultaneously on the same piece in a distributed arrangement. The FrankenScore backend can run in the cloud with multiple people collaborating on the same piece. Multiple pieces can be open simultaneously to allow copy-and-paste operations between them.

My next steps involve implementing file persistence (saving and opening music files), as well as tackling printing. These are foundational features, not mere add-ons. Persistence forces a clear definition of the data model and enables easier testing. Printing isn't just about output; it's about representation and serves as a sanity check on the entire system design. Both will likely inform further refinements of the core architecture, potentially revealing oversights or opportunities for optimisation.

Additionally, sequencing is a crucial part of the core platform. And by sequencing I mean support for converting musical representations to timed sound events - though not necessarily via MIDI; a software synth may use direct means of control, for instance. The core sequencer can be used by plugins to generate MIDI, or to input MIDI, but the actual MIDI implementation will be done in the plugin layer. But that's a whole blog post of its own.

The past four weeks have been a whirlwind of productivity. Enjoying a deep creative flow, I've really been wind-surfing through parentheses as I've been working almost around the clock on FrankenScore. The results have been surprising:

• Core Platform: The massively concurrent core engine will be complete in a matter of days, providing a robust, high-performance platform for ACID-compliant transactions.
• API: The polymorphic API is almost finished as well, allowing clients to easily manipulate musical structures in a powerful and intuitive way.
• Documentation and Website: A comprehensive wiki and a live website are now available, serving as central resources for the project.

This initial rush has successfully got FrankenScore off the ground, building a strong foundation in record time. However, as my holiday draws to its close and my day job with Delegat AB resumes, the pace will inevitably slow down a little.

The timeline for releasing FrankenScore as open source depends on several factors, including the presence of internal collaborators before the public release. While the foundational work is largely complete, the project will continue to evolve at a steadier pace.

If I'm left entirely to my own devices without any pre-release assistance, I should say the public open source release of Ooloi 0.x will happen in about a year's time. With collaborators, in about six months or so. But this is difficult to gauge with any exactness, as there are so many variables involved.

Also, after going public, remember Ooloi won't be finished by any means. That's when the journey begins in earnest, travelling the distance from Ooloi 0.x to 1.0. But then we'll be travelling as a group.

Anyway, there'll be regular status and road map updates on this blog. I'll keep you posted.

FrankenScore is still private. There is a number of things that need to be in place before the project can go public and I can start inviting collaborators, so let's touch a little on names, releases and versions.

At this stage I'm finalising the robust, high-performance platform for ACID-compliant transactions which forms the basis of everything in FrankenScore and is manifested through the backend API.

FrankenScore becomes Ooloi when released as open source. But the first release doesn't need to be Ooloi 1.0, which by definition would be feature-complete. In fact, it should be Ooloi 0.n with an n as low as possible, meaning it's best to go public as early as possible, yet feature-complete enough so Ooloi's promise is immediately apparent.

Here's a very rough project plan:

1. Finalise the API (nearly done)
2. Implement File Persistence using Fressian (saving and loading pieces)
3. Implement gRPC Layer and Event Handling (for communication between the backend and the frontend)
4. Create Initial Frontend with Hello World Window (proof of concept)
5. Implement printing in the frontend client (of the Hello World Window)
6. Implement enough of the frontend/backend interaction so that a score can be set up and simple elements can be entered and manipulated. This is an complex. multi-step process that also involves setting up event handling in the frontend. It's the basis for everything that is to come and must be rock solid.
7. Implement measure reformatting locally for measures according to a simple linear method that will be upgraded later
8. Implement backend reformatting and reflow of measures over systems and pages
9. Iteratively add more notational elements and features until Ooloi 0.n can be released, meaning that the project is released as open source.
10. After the release, adding more notational elements continues in parallel with the remaining points:
11. Implementation of a more advanced measure formatting algorithm
12. Implementation of the plugin system.
13. Implementation of an open source plugin for simple MIDI in- and output.
14. Implementation of an open source plugin for reading and writing MusicXML files.
15. When all notational elements are supported, Ooloi 1.0 can be released.

​So, point 9 represents the point where the project goes public and Ooloi 0.n appears. It remains to be seen how feature-complete the notation must be to confidently take that step.

However. There might of course be room for collaborators in the project before the public release as open source, as there are points in the above list that cover isolated features that could be delegated to an experienced Clojure programmer. Hmm. Let's think about that.