Sobre el proyecto

Muse Next es una recreación moderna del editor de partituras nativo de Windows Muse Pro 2.70, que ya no recibe mantenimiento. Utiliza TypeScript, Electron y React, y sigue el principio clean-room: no porta el código original ni recursos sujetos a derechos de autor. Sus objetivos principales, en orden, son restaurar la lectura y escritura del formato privado de partituras .jcx, la representación de la partitura, la edición y la reproducción. El análisis inverso confirmó que .jcx no es binario, sino un formato de texto plano basado en ABC notation con extensiones privadas de Muse, que incluye style de voces, diagramas de acordes %%gchord, TAB de guitarra, anotaciones de notación numerada, etc. Por ello, el proyecto no usa bibliotecas ABC existentes ni toma el motor de notación como modelo interno. La arquitectura emplea una canalización unidireccional: tras decodificar los bytes se obtiene el texto fuente Muse; el lexer produce un flujo de tokens en modo dual pitch-mode y tab-mode; luego se construye un AST sin pérdida que puede restaurar byte a byte el texto decodificado mediante printAst; después se analiza a un Domain Score normalizado, con modelos autoritativos como Voice, MusicEvent y Relation; finalmente se serializa a un texto que, en modo preserve, restaura el original byte a byte o, en modo canonical, produce una forma estándar. Las capas de aplicación, como renderizado y edición, solo pueden depender del Domain, y no deben analizar directamente texto JCX ni manipular el AST. Las restricciones de diseño incluyen: el Scanner solo realiza clasificación y estadísticas; ante lo desconocido debe conservarse explícitamente; la semántica UNVERIFIED no entra en el tipado fuerte del Domain; la prioridad de evidencia es corpus real mayor que documentación de ayuda original mayor que estándar ABC. En el directorio, src/domain es el modelo autoritativo y tiene prohibido depender de capas de formato, renderizado, etc.; src/formats/jcx ofrece conversión bidireccional, con encoding, lexer, ast, parse, serialize y utilidades de proyección semántica, y su entrada pública es src/formats/jcx/index.ts. La API pública ofrece loadJcx para leer bytes o texto a Score, diagnostics, lex y ast; serializeJcx admite el modo preserve, que restaura byte a byte, y el modo canonical, que emite texto UTF-8 estándar con cabecera %MUSE2. Los hitos M0 a M1.8 ya están completados, abarcando el andamiaje de Electron, el escaneo de corpus, la documentación de especificación JCX, el lexer, el AST sin pérdida, el Parser, el Serializer y las barreras de compatibilidad round-trip, con CI aprobada en tres plataformas. M2 Notation Rendering, cerrado el 2026-09-22, ya implementa, a partir del Domain Score, el renderizado de cuatro tipos de notación: diagramas de acordes, notación numerada, TAB de guitarra y pentagrama. Staff depende unidireccionalmente mediante un adaptador de VexFlow; la capa de renderizado cuenta con una matriz de pruebas de contrato; en todo el repositorio pasan 5642 casos de prueba en 74 archivos. La siguiente etapa es M3 Editor Core: cursor de selección, arquitectura de comandos, deshacer/rehacer y sincronización con la visualización del código fuente. Después se planifican reproducción, importación/exportación MIDI, diseño y distribución. El desarrollo requiere Node.js ≥22.12 y ofrece comandos como typecheck, test, jcx:corpus-test y jcx:fixture-report; la CI se ejecuta en una matriz de macOS, Windows y Ubuntu. Las barreras de calidad verifican mediante una matriz de fixtures seis aspectos: parse, semantic, preserve byte-identical, idempotent, closure y reparse-clean, y registran explícitamente las limitaciones conocidas como pinned known limitation. El proyecto no incluye el ejecutable del programa original, partituras integradas ni fuentes propietarias; el corpus se guarda localmente y queda excluido por gitignore.