About this project

Muse Next is a modern remake of the discontinued Windows-native Muse Pro 2.70 score editor, built with TypeScript, Electron, and React, following clean-room principles without porting original code or copyrighted resources. The core goals, in order, are to restore reading and writing of the proprietary score format .jcx, score rendering, editing, and playback capabilities. Reverse engineering confirmed that .jcx is not binary, but rather a plain-text format based on ABC notation with Muse proprietary extensions layered on top, including voice styles, %%gchord chord diagrams, guitar TAB, and numbered musical notation annotations. The project therefore does not use an off-the-shelf ABC parsing library, nor does it use a notation engine as its internal model. The architecture uses a unidirectional pipeline: after byte decoding, the Muse source text is obtained, passed through a lexer to produce a dual-mode token stream in pitch-mode and tab-mode, then an lossless AST is built, which can restore the decoded text byte-for-byte via printAst. It is then parsed into a normalized Domain Score, containing authoritative models such as Voice, MusicEvent, and Relation, and finally serialized into text in either preserve mode, restoring the original byte-for-byte, or canonical mode, producing a standard form. Application layers such as rendering and editing may only depend on the Domain and must not directly parse JCX text or manipulate the AST. Design constraints include: the Scanner only performs classification and statistics, unknown content must be explicitly preserved, UNVERIFIED semantics do not enter the Domain strong types, and the evidence priority is real corpus over original help documentation over the ABC standard. In the directory structure, src/domain is the authoritative model and is forbidden from depending on format, rendering, or other layers; src/formats/jcx provides bidirectional conversion, including encoding, lexer, ast, parse, serialize, and semantic projection utilities, with the public entry point at src/formats/jcx/index.ts. The public API provides loadJcx to read bytes or text into Score, diagnostics, lex, and ast; serializeJcx supports preserve mode for byte-for-byte restoration and canonical mode for outputting UTF-8 standard text with a %MUSE2 header. Milestones M0 through M1.8 have been completed, covering the Electron scaffold, corpus scanning, JCX specification documentation, lexer, lossless AST, Parser, Serializer, round-trip compatibility guardrails, and passing CI on three platforms. The M2 Notation Rendering milestone, frozen on 2026-09-22, has implemented rendering of four notations from the Domain Score: chord diagrams, numbered musical notation, guitar TAB, and standard staff notation. Staff depends unidirectionally on the VexFlow adapter, the rendering layer has a contract test matrix, and the entire repository passes 74 test files with 5,642 test cases. The next phase is M3 Editor Core, covering selection cursors, command architecture, undo/redo, and source visualization synchronization, with later plans for playback, MIDI import/export, layout, and distribution. Development requires Node.js ≥22.12 and provides commands such as typecheck, test, jcx:corpus-test, and jcx:fixture-report, with CI running on a macOS, Windows, and Ubuntu matrix. Quality guardrails check six properties through the fixture matrix: parse, semantic, preserve byte-identical, idempotent, closure, and reparse-clean, with known limitations explicitly registered as pinned known limitations. The project does not include the original program executable, built-in scores, or proprietary fonts; the corpus is stored locally and excluded by gitignore.