muse-next

Muse Next est une réédition moderne de l'éditeur de partitions Windows natif Muse Pro 2.70, désormais abandonné. Elle repose sur TypeScript, Electron et React, et suit le principe clean-room sans porter le code original ni des ressources sous copyright. Les objectifs principaux sont, dans l'ordre : restaurer la lecture/écriture du format de partition propriétaire .jcx, le rendu de la partition, l'édition et la lecture. L'analyse inverse confirme que .jcx n'est pas binaire, mais un format texte basé sur la notation ABC, enrichi d'extensions propriétaires Muse : style de voix, diagrammes d'accords %%gchord, tablature de guitare, annotations de notation numérique, etc. Le projet n'utilise donc pas de bibliothèque d'analyse ABC existante et ne fait pas du moteur de notation un modèle interne. L'architecture suit un pipeline unidirectionnel : après décodage des octets, on obtient le texte source Muse ; le lexer produit un flux de tokens en double mode pitch-mode et tab-mode ; on construit ensuite un AST non destructif, capable de restaurer octet par octet le texte décodé via printAst ; puis on analyse vers un Domain Score normalisé, avec les modèles faisant autorité Voice, MusicEvent, Relation, etc. ; enfin on sérialise en texte preserve, restauré octet par octet, ou canonical, forme standard. Les couches applicatives comme le rendu et l'édition ne peuvent dépendre que du Domain, et ne doivent pas analyser directement le texte JCX ni manipuler l'AST. Les contraintes de conception incluent : le Scanner ne fait que de la classification et des statistiques ; toute inconnue doit être explicitement préservée ; la sémantique UNVERIFIED n'entre pas dans le typage fort du Domain ; la priorité des preuves est : corpus réel supérieur à la documentation d'aide originale supérieure au standard ABC. Dans l'arborescence, src/domain est le modèle faisant autorité et interdit toute dépendance aux couches de format ou de rendu ; src/formats/jcx fournit la conversion bidirectionnelle, avec encoding, lexer, ast, parse, serialize et des outils de projection sémantique ; le point d'entrée public est src/formats/jcx/index.ts. L'API publique fournit loadJcx pour lire des bytes ou du texte vers Score, diagnostics, lex, ast ; serializeJcx prend en charge le mode preserve, restauration octet par octet, et le mode canonical, sortie texte UTF-8 standard avec en-tête %MUSE2. Les jalons M0 à M1.8 sont terminés : échafaudage Electron, scan du corpus, documentation de spécification JCX, lexer, AST non destructif, Parser, Serializer, garde-fous de compatibilité round-trip, validés par la CI sur trois plateformes. M2 Notation Rendering, figé le 2026-09-22, implémente depuis le Domain Score le rendu de quatre notations : diagrammes d'accords, notation numérique, tablature de guitare et portée. Staff dépend unidirectionnellement de l'adaptateur VexFlow ; la couche de rendu dispose d'une matrice de tests de contrat ; l'ensemble du dépôt passe 5642 cas dans 74 fichiers de tests. La prochaine étape est M3 Editor Core : curseur de sélection, architecture de commandes, annulation/rétablissement et synchronisation de la visualisation du code source ; ensuite sont prévus la lecture, l'import/export MIDI, la mise en page et la distribution. Le développement exige Node.js ≥22.12 et fournit les commandes typecheck, test, jcx:corpus-test, jcx:fixture-report, etc. La CI s'exécute sur une matrice macOS, Windows, Ubuntu. Les garde-fous de qualité vérifient via une matrice de fixtures six points : parse, semantic, preserve byte-identical, idempotent, closure, reparse-clean, et enregistrent explicitement les limitations connues via pinned known limitation. Le projet ne contient pas l'exécutable original, ni de partitions intégrées, ni de polices propriétaires ; le corpus est stocké localement et exclu par gitignore.