L'écriture de la musique est un langage très précis. De ce fait l'édition de la musique pourrait être simplifiée et éventuellement améliorée, si on séparait la saisie de la mise en forme de la partition. En effet, au moment de la saisie, l'outil d'édition doit avoir une représentation très mathématique de la partition. Il doit ainsi espacer automatiquement les notes, permettre l'insertion et la justification. Mais d'un autre côté, lors d'une mise en forme, comme par exemple la décision du nombre de mesures par ligne, ou tout simplement le déplacement d'une note pour mieux aérer une mesure, l'outil doit faire abstraction de ces paramètres et permettre ces modifications.
Quand ces deux opérations se font dans un ordre préétabli, saisie puis mise en forme, le problème n'a pas lieu d'être. Toute la difficulté consiste à passer d'un mode à l'autre sans changer d'outil et donc de représentation interne de la partition.
Certains logiciels existants (comme Berlioz), fixent l'ordre dans lequel doivent se produire ces opérations et ne permettent pas de retour en arrière : on saisit la partition, puis on la met en forme. Une fois cette opération terminée, toutes les insertions de notes deviennent purement graphiques sans aucune possibilité d'aide à l'édition.
Les autres sont obligés soit de limiter les possibilités de mise en forme (impossible de déplacer graphiquement des symboles) soit d'offrir une saisie pas assez fluide où, par exemple, l'utilisateur est obligé de fixer à l'avance le nombre de mesures par système.
Pour pallier ce problème il est nécessaire d'avoir un modèle interne de la partition aussi graphique que musical. En d'autres termes, pour chaque note, il faut avoir une représentation contenant non seulement son emplacement physique, ses espacements par rapport aux notes précédente et suivante (espace avant et espace après) et son symbole, mais aussi son emplacement musical (son rang dans la voix) et ses différents attributs comme début d'un coulé, fin d'un lien, pointée, etc.
Toutes ses données doivent ensuite être gérées en fonction des actions de l'utilisateur: les attributs musicaux (comme le rang par exemple) prévalent par défaut, mais une fois la note déplacée ou modifiée, ce sont les attributs graphiques qui prennent le relais.
La note n'est plus placée seulement en fonction de son rang dans le flux musical, mais aussi en fonction des modifications de l'utilisateur.
Pour illustrer ces propos, la figure 2.4 montre un exemple très simple d'une mesure qui vient d'être saisie.
La première note a dans ce cas les attributs suivants :
Symbole : noire
Hauteur/interligne : 0
Position : 1
Espacement avant : 0
Espacement après : espacement d'une noire par défaut
etc.
La deuxième note a les mêmes caractéristiques sauf sa position.
Supposons maintenant que l'utilisateur déplace la deuxième note d'une
distance x vers
la droite (figure 2.5)
L'utilisateur peut toujours vouloir insérer des notes avant et vouloir que les notes se décalent sans perdre cette mise en forme, le champ Espacement après de la première note devient : espacement d'une noire par défaut + x; et le champ Espacement après de la deuxième note soit reste inchangé (et là la suite se décale) soit devient Espacement d'une noire par défaut -x;
L'erreur à éviter est donc d'attribuer à la note des coordonnées propres (x,y) qui, même si elles augmentaient la liberté d'édition, bloqueraient ses possibilités d'insertion, de décalage, etc.
