OOLOI.ORG
Menu

FRANKENSCORE

A Body Resurrected.

OVERVIEW

DOCUMENTATION

Road Map

8/8/2024

0 Comments

 
Picture
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.
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    Author

    Peter Bengtson –composer, organist, programmer, cloud architect. Currently windsurfing through parentheses.

    View my profile on LinkedIn

    Archives

    April 2025
    March 2025
    September 2024
    August 2024
    July 2024

    Categories

    All
    Architecture
    Clojure
    CLOS
    Common Lisp
    Documentation
    Finale
    FrankenScore
    Franz Kafka
    Functional Programming
    Generative AI
    Igor Engraver
    Jacques Derrida
    JVM
    Lisp
    Ooloi
    Python
    Rich Hickey
    Road Map
    Scheme
    Sibelius
    Site

    RSS Feed

Home
​Overview
Documentation
About
Contact
FrankenScore is a modern, open-source music notation software designed to handle complex musical scores with ease. It is designed to be a flexible and powerful music notation software tool providing professional, extremely high-quality results. The core functionality includes inputting music notation, formatting scores and their parts, and printing them. Additional features can be added as plugins, allowing for a modular and customizable user experience.​
  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Introduction for Anti-Capitalists
    • Technical Comparison
  • Documentation
    • Architectural Decision Log >
      • Choice of Clojure
      • Separation of Frontend and Backend
      • Adoption of gRPC
      • Plugins
      • STM for Concurrency
      • JavaFX & Skija
      • SMuFL
      • Nippy
      • Vector Path Descriptors
      • Collaborative Features
      • Trees and Circles
      • Shared Structure
      • Persisting Pieces
      • Slur Formatting
    • Backend src README
    • Development Plan
    • License
    • Code of Conduct
  • About
  • Contact
  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Introduction for Anti-Capitalists
    • Technical Comparison
  • Documentation
    • Architectural Decision Log >
      • Choice of Clojure
      • Separation of Frontend and Backend
      • Adoption of gRPC
      • Plugins
      • STM for Concurrency
      • JavaFX & Skija
      • SMuFL
      • Nippy
      • Vector Path Descriptors
      • Collaborative Features
      • Trees and Circles
      • Shared Structure
      • Persisting Pieces
      • Slur Formatting
    • Backend src README
    • Development Plan
    • License
    • Code of Conduct
  • About
  • Contact