Docstoc

rapport

Document Sample
rapport Powered By Docstoc
					                Projet SAR6 - Internet




        M U S IQU E -XM L
           V E R S SVG

UN GENERATEUR DE PARTITIONS DE MUSIQUE




        François Chastanet francois.chastanet@free.fr
       Antoine Paolini(FC) paolini@essi.fr
              FX Vila(FC) fxvila@essi.fr
SAR 6 – INTERNET                                                                                                     MUSIQUE-XML -> SVG



                                                      0      TA B L E D E S M A T I E R E S



0      Table des Matières ........................................2               2.4 Fonctionnement Général ........................ 7
1      Introduction ..................................................2           2.5 Le Moteur ................................................ 8
    1.1 Objectif: ...................................................2            2.6 Description du format MusiXML .......... 9
    1.2 Les technologies:......................................2              3      Deuxième Etude ......................................... 10
    1.3 Nos Connaissances: .................................2                     3.1 Diagramme de Classes(Version 3) ....... 10
                                                                                    3.1.1 Le parser.......................................... 10
    1.4 Limitations: ..............................................2
                                                                                    3.1.2 La structure de Données .................. 11
    1.5 Evaluation du prototype: ........................2                          3.1.3 Le moteur de génération.................. 12
    1.6 Finalité du projet: ...................................2                    3.1.4 finalement........................................ 12

    1.7 Extensions possibles: ...............................2                    3.2 Fontes SVG ............................................ 13
                                                                                    3.2.1 GEneration du fichier de police ...... 13
    1.8 Un peu de vocabulaire ............................3                         3.2.2 Generation du fichier SVG.............. 13
2      Première Etude .............................................4                3.2.3 Exemple de generation .................... 14

    2.1 Choix de la DTD ......................................4               4      Travail Déjà Effectué ................................. 15

    2.2 Exemple de fichier SVG..........................5                         4.1 Répartition Du Travail ......................... 15

    2.3 Aperçu de Batik affichant ce svg ...........6                         5      Conclusion .................................................. 16

Table des Figures
Figure 1: définitions des différents termes                               Figure 6: Arbre décrivant le format MusiXML ......... 9
musicaux(les termes entre parenthèses sont les                            Figure 7: Diagramme de classes du parser ............ 10
traductions en français) ............................................ 3   Figure 8: Diagramme de classes de la structure de
Figure 2 : aperçu de Batik ........................................ 6     données .................................................................... 11
Figure 3: présentation du fonctionnement général ... 7                    Figure 9: Diagramme de classes du Moteur de
Figure 4: Exemple d'alignement de notes ................. 8               génération................................................................ 12
Figure 5: Exemple d'alignement de notes en utilisant                      Figure 10 Exemples de Fontes Classique et Jazz .... 14
l'algorithme Engraver ............................................... 9




     François Chastanet, Antoine Paolini, François -Xavier Vila                                                                           2/16
SAR 6 – INTERNET                                                                         MUSIQUE-XML -> SVG



                                              1       I N T ROD U C T I ON


1.1       OBJECTIF:

    Notre objectif est de réaliser un logiciel qui permettra de transformer un document écrit dans le format
MusiXML(ou un équivalent) en un document au format SVG. Ce document pourra être affiché graphiquement
par Batik, en attendant que les browsers intègrent les fonctionnalités SVG.

1.2       LES TECHNOLOGIES:

     Nous utilisons les technologies XML et SVG, le langage C++ pour l’analyseur syntaxique, l'outil Batik pour
la visualisation des documents SVG résultants.

1.3       NOS CONNAISSANCES:

    Nos connaissances actuelles sur XML se limitent à la présentation SAR6 sur ce sujet, et à quelques
expérimentations en stage.

      Nous découvrons SVG, par conséquent Batik, et le C++.

      Bonnes connaissances de la musique pour 2 d'entre nous.

1.4       LIMITATIONS:

      Nous nous limiterons à une représentation simplifiée d'une partition.

1.5       EVALUATION DU PROTOTYPE:

      1. création d'un fichier MusiXML à la main(respect de la DTD)

      2. analyse du fichier et création du fichier SVG (prototype)

      3. affichage du fichier résultant dans Batik.

1.6       FINALITE DU PROJET:

      Afficher des partitions de musique sur le Web stockées au format XML.

1.7       EXTENSIONS POSSIBLES:

      -    Un éditeur de musique qui enregistre au format XML(pour créer facilement nos propres partitions).

      -    Un convertisseur bidirectionnel XML->MIDI, MIDI->XML




      François Chastanet, Antoine Paolini, François -Xavier Vila                                       2/16
SAR 6 – INTERNET                                                                                            MUSIQUE-XML -> SVG


1.8     UN PEU DE VOCABULAIRE




           Figure 1: définitions des différents termes musicaux(les termes entre parenthèses sont les traductions en français)

     L’indication de la mesure se définit par une indication du nombre de battements par mesure(beat per
measure=bpm) et de la valeur de ces battements(value of beat=vob). Par exemple une mesure à 2/4 signifie qu’il
y a 2 battements de durée ¼, l’unité étant la ronde. On aura donc 2 noires par mesure.

    Ainsi une noire vaut la moitié d'une blanche, une croche vaut la moitié d'une noire, et ainsi de suite. (dans le
schéma, les 2 premières notes sont des croches, la suivante est une noire, et dans la mesure suivante, on a une
blanche.




      François Chastanet, Antoine Paolini, François -Xavier Vila                                                                 3/16
SAR 6 – INTERNET                                                                           MUSIQUE-XML -> SVG



                                             2    PREMIERE ETUDE


2.1     CHOIX DE LA DTD

      Plusieurs DTDs ou XMLSchema sont disponibles sur le net.

    Certaines favorisent la notation d’instrument pour pouvoir jouer un morceau synthétiquement (FlowML),
d’autres favorisent l’édition, et d ‘autres l’affichage.

     Comme la musique s’exprime sur 2 dimensions (le temps et les portées), certains formats XML ont 2 DTDs
distinctes pour représenter la musique sous 2 angles différents(MusicXML).

      On aimerait regrouper, hors du cadre de ce projet, en un seul format toutes ces caractéristiques.

     Un problème fondamental en représentation musicale, c’est que : non seulement il faut s’occuper de la
représentation horizontale et verticale des notes(2 dimensions), mais il faut aussi se soucier de l’alignement des
différentes parties(=portées) pour une meilleure lisibilité (habitude des musiciens).

    On pourrait aussi imaginer de coupler ce logiciel à SMIL ou à VoiceXML, dans le cas où on voudrait générer
la voix à partir des paroles et de la musique(pour les années à venir), ou encore se baser sur les spécifications
MPEG-4 et MPEG-7. Mais tout ceci est hors du cadre de ce projet.

   A l’heure actuelle, il n’existe aucun format standard, il a donc fallu choisir parmi une dizaine de formats.
Nous avons choisi le format MusiXML qui a le mérite d’avoir une DTD et une description à base de
XMLSchema. (cf. rapport de remarques)

     A l'origine du projet, nous avions créé notre propre DTD. Mais les difficultés de conception, nous ont fait
choisir une DTD déjà existante(cf. rapport précédent pour voir notre DTD). La création de cette DTD n'a pas
été inutile car elle nous a permis de cerner les difficultés que nous allions rencontrer lors de l'implémentation et
aussi, elle nous a permis de créer une structure de données réutilisable, car celle-ci existait déjà avant le
changement de DTD, et nous n'avons pas eu beaucoup de changements à faire pour passer à MusiXML
(seulement quelques éléments auxquels nous n'avions pas pensé au départ).

    L’étude de ce format, nous a fait changer un certain nombre d ‘éléments du diagramme de classes. (des
éléments que nous n'avions pas prévu). En particulier la balise "chord", dans notre DTD, on avait un attribut de
la note qui disait si on était dans un accord ou pas (Un accord ou chord, pour simplifier, c'est le fait de jouer
plusieurs notes en même temps).

    De toutes façons, l’intérêt de XML réside dans le fait qu’avec une feuille XSLT il est possible de passer d’un
format à un autre, donc le changement de DTD ne pose pas de problème(ou seulement le fait de créer la feuille
de style XSLT).




      François Chastanet, Antoine Paolini, François -Xavier Vila                                          4/16
SAR 6 – INTERNET                                                     MUSIQUE-XML -> SVG


2.2     EXEMPLE DE FICHIER SVG
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN"
  "http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd">
<svg width="800" height="600" viewBox="0 0 1000 600">
<g transform="scale(0.714)" >
<line x1="50" y1="150" x2="950" y2="150" style="stroke-width:1; stroke:black"   />
<line x1="50" y1="200" x2="950" y2="200" style="stroke-width:1; stroke:black"   />
<line x1="50" y1="250" x2="950" y2="250" style="stroke-width:1; stroke:black"   />
<line x1="50" y1="300" x2="950" y2="300" style="stroke-width:1; stroke:black"   />
<line x1="50" y1="350" x2="950" y2="350" style="stroke-width:1; stroke:black"   />

         <g transform="translate(300 175)">
                <ellipse rx="30" ry="25"
                  style="fill:black" />
         <line x1="28" y1="0" x2="28" y2="-130"
                   style="stroke-width:3; stroke:black" />
         </g>
         <g transform="translate(450 325)">
                <ellipse rx="30" ry="25"
                  style="fill:black" />
         <line x1="28" y1="0" x2="28" y2="-130"
                   style="stroke-width:3; stroke:black" />
         </g>
</g>
</svg>




      François Chastanet, Antoine Paolini, François -Xavier Vila                     5/16
SAR 6 – INTERNET                                                           MUSIQUE-XML -> SVG


2.3     APERÇU DE BATIK AFFICHANT CE SVG




                                              Figure 2 : aperçu de Batik

         Voici, le résultat de notre première approche avec Batik.




      François Chastanet, Antoine Paolini, François -Xavier Vila                     6/16
SAR 6 – INTERNET                                                                        MUSIQUE-XML -> SVG


2.4     FONCTIONNEMENT GENERAL




                                    Figure 3: présentation du fonctionnement général

    Un fichier au format MusiqueXML(détaillé plus haut est entré dans le parser(analyseur syntaxique) du type
SAX(plus rapide, et nous permet de générer la structure de données que l'on veut, nous n'avions pas besoin de
DOM). Ce parser génère une structure de données qui est ensuite utilisée par le moteur pour générer le fichier au
format SVG.




      François Chastanet, Antoine Paolini, François -Xavier Vila                                       7/16
SAR 6 – INTERNET                                                                            MUSIQUE-XML -> SVG


2.5       LE MOTEUR

     Un point important dans la représentation musicale est, pour que cette représentation soit lisible, il faut
aligner les notes de 2 portées différentes les unes en-dessous des autres, en fonction de leur temps de départ et de
leur durée.



      Par exemple :




                                         Figure 4: Exemple d'alignement de notes

      Nous connaissons 2 types d'algorithme de positionnement de notes:

      -   l'algorithme de positionnement constant (nous l'avons appelé ConstantMusicLayer):

     Il permet de placer les notes très simplement, en donnant pour des notes de durées différentes, des distances
différentes, l’alignement des notes se fait donc automatiquement.

      Remarque :nous n’implémenterons que le ConstantMusicLayer, en raison du temps qui nous est imparti.

        - l’algorithme de positionnement dynamique (nous l'avons appelé EngraverMusicLayer, pour reprendre le
terme utilisé dans les éditeurs de musique), il consiste à réduire l’espace entre 2 notes quand cela est possible.
Voici une petite description de ce qu'il faudrait faire:

    Une fois la structure de données en mémoire avec des valeurs par défaut pour les différentes données, on
parcourt cette structure, mesure par mesure.

      On place les notes dans la mesure sans se soucier des autres portées.

    Ensuite grâce à un système de positionnement de la mesure (x, y), on peut faire ceci pour chaque mesure
indépendamment du reste.

     Ensuite une fois l’espace calculé pour chaque mesure, on va parcourir à nouveau chaque mesure à partir de la
deuxième portée, et ajuster l’espacement entre les notes de la mesure située juste au-dessus de la mesure
courante(donc la portée précédente). On aligne ainsi chaque mesure par rapport à ses mesures-sœurs(situées
verticalement). Si la mesure-sœur est modifiée (agrandie), il y a juste à changer l’offset des mesures restantes sur la
portée de la mesure-sœur (on voit donc pourquoi, on parle de deux dimensions).

     Une fois la structure de données parcourue une deuxième fois il n’y a plus qu’à placer les mesures, suivant
l’espace disponible sur la page.

      On génère ensuite le SVG(ou autre chose) à partir de la structure de données.




      François Chastanet, Antoine Paolini, François -Xavier Vila                                            8/16
SAR 6 – INTERNET                                                                                        MUSIQUE-XML -> SVG


      Cet algorithme devrait pouvoir aider à générer des mesures dans ce genre :




                           Figure 5: Exemple d'alignement de notes en utilisant l'algorithme Engraver

    Remarquez que la première mesure prend moins de place que la seconde. Pourtant le temps d’éxécution (de
la musique) est le même.

2.6     DESCRIPTION DU FORMAT MUSIXML




                                        Figure 6: Arbre décrivant le format MusiXML




      François Chastanet, Antoine Paolini, François -Xavier Vila                                                  9/16
SAR 6 – INTERNET                                                                          MUSIQUE-XML -> SVG



                                             3    DEUXIEME ETUDE


3.1       DIAGRAMME DE CLASSES(VERSION 3)


3.1.1      LE PARSER




                                         Figure 7: Diagramme de classes du parser

     En fait, pour plus de souplesse, nous avons 3 analyseurs syntaxiques (chacun de ces parsers analyse des
fichiers qui ont une DTD respective):

      -    GlyphHandler génère une Hastable de glyphes musicaux(cf. création des glyphes)

      -    PageInfoHandler génère une Hashtable d'informations sur la partition, c'est-à-dire les marges, les
           espacements minimums entre les classes de glyphes, le layer utilisé (cf. Le Moteur). On pourrait imaginer
           par la suite de remplacer ceci par une feuille de style. Nous n'avons pas implémenté cette partie.

      -    MusiqueHandler génère la structure de données à partir d'un fichier au format MusiXML.

    Ceci nous permet de n'avoir qu'une instance du parser, et de changer seulement le handler suivant nos
besoins.




      François Chastanet, Antoine Paolini, François -Xavier Vila                                         10/16
SAR 6 – INTERNET                                                                            MUSIQUE-XML -> SVG


3.1.2   LA STRUCTURE DE DONNEES




                                Figure 8: Diagramme de classes de la structure de données

    Un Score est composée de Staffs qui elles-mêmes sont composées de Measures. La Staff est la représentation
horizontale de la partition, chaque Staff représente une portée. La MasterMeasure est la représentation verticale.

    Une Measure est composé d'objets de type MusicElement (Note, Rest, GraphicBar).

    Enfin pour représenter, les éléments musicaux qui sont au-dessus des mesures, nous avons des groupes (Tie,
Beam, Slur) d'éléments de musique(Note, Rest).




   François Chastanet, Antoine Paolini, François -Xavier Vila                                          11/16
SAR 6 – INTERNET                                                                          MUSIQUE-XML -> SVG




3.1.3   LE MOTEUR DE GENERATION




                                 Figure 9: Diagramme de classes du Moteur de génération

     Le ConstantMusicLayer permet de placer les notes très simplement, en donnant pour des notes de durées
différentes, des distances différentes, l’alignement des notes se fait donc automatiquement. Le SVGGenerator dans
l'implémentation actuelle contient des méthodes pour générer le SVG facilement. Il contient aussi la liste des
glyphes SVG parsés précédemment par le GlyphHandler.

    L’interface FormatGenerator permet à quelqu’un qui voudrait générer autre chose que du SVG, de se faire sa
propre classe et de donner l’instance de cette nouvelle classe au SpacingAlgorithm.

    Remarque :nous n’avons implémenté que le ConstantMusicLayer, Le EngraverLayer consiste à réduire l’espace
entre 2 notes quand cela est possible.


3.1.4   FINALEMENT

    Notre programme pourra s’utiliser en fait comme une API, l’utilisateur pourra parser le fichier, ce qui lui
générera une structure de données, qui pourra à son tour générer du SVG(ou autre chose). Le fait d'avoir sorti les
glyphes de l'implémentation, nous a été très profitable pour ajuster les différents glyphes, sans avoir à tout
recompiler à chaque fois, de plus on pourrait imaginer changer la police(le fichier de glyphes) pour afficher une
partition au style Jazz par exemple.




   François Chastanet, Antoine Paolini, François -Xavier Vila                                          12/16
SAR 6 – INTERNET                                                                             MUSIQUE-XML -> SVG


3.2     FONTES SVG


3.2.1     GENERATION DU FICHIER DE POLICE

         Ce dernier a été obtenu à partir d'un fichier de police "true type". Les caratères "utiles" ont été vectorisés
un par un à l'aide du logiciel Adobe Illustrator, et repositionés dans le plan par rapport à une origine commune à
chaque caractère.
         Illustrator dans sa version 9, permet la conversion au format SVG. Nous avons utilisé cette fonctionalité
pour la convertion de chaque caractère.

Scénario:
         police "TrueType" -> Un caratère -> vectorisation (Illustrator 9) fichier.ai -> fichier.SVG

          Chaque fichier SVG est ensuite concaténé dans le fichier XML glyph.cfg.

3.2.2     GENERATION DU FICHIER SVG

        A ce stade, le fichier XML est parsé et les emplacements des notes et autres figûres sont calculés. La
dernière étape consiste donc à générer le fichier SVG final. Pour ce faire, nous avons constitué un fichier de
police de notes, ainsi qu'un ensemble de méthodes pour y accéder. Pendant la phase d'affichage, le moteur
invoque ces méthodes en passant en paramètre les coordonnées de la figûre à dessiner.

        Le choix d'un fichier de police de notes, baptisé glyph.cfg, permet à l'utilisateur final de choisir la fonte
de son choix. Ci-dessous un exemple de fonte "jazz" et "classique".

Le fichier de police est au format XML (qu'il faut donc parser !). Sa DTD se résume à :

<!ELEMENT glyphs (glyph*)>
<!ELEMENT glyph (#PCDATA) >
<!ATTLIST glyph
 name CDATA #REQUIRED
 width CDATA #IMPLIED <!-- largeur de la figűre -->
 height CDATA #IMPLIED <!-- hauteur -->
 baseline CDATA #IMPLIED <!-- ligne de base: pour le positionnement vertial -->
>

Par exemple, pour une "pause" on obtient la chaine svg suivante:

<glyph name = "PAUSE" width='24' height='8' baseline='0'>
<![CDATA[
<path style="&st1;" d="M2.469,8.25H0V7.409h23.969V8.25H21.5v7.159H2.469V8.25z"/>
]]>
</glyph>

         Certains glyphs sont recalculées dynamiquement en utilisant les propriétés SVG. Par exemple la queue de
la croche inverse est générée à partir de la queue de la croche normale en faisant subir à celle-ci une
transformation du type :
<g transform="matrix(1 0 0 -1 0 0)">

Ceci permet de limiter le nombre de glyphes à générer dans le fichier de police.




      François Chastanet, Antoine Paolini, François -Xavier Vila                                            13/16
SAR 6 – INTERNET                                                              MUSIQUE-XML -> SVG


3.2.3   EXEMPLE DE GENERATION




                             Figure 10 Exemples de Fontes Classique et Jazz




   François Chastanet, Antoine Paolini, François -Xavier Vila                           14/16
SAR 6 – INTERNET                                                                      MUSIQUE-XML -> SVG



                                       4   T R AVA I L D E JA E F F E C T U E


      Nous avons achevé l’étude et la conception. Nous entamons dès maintenant la phase d’implémentation.

     Au 15/02/2001, nous avons réalisé toutes les classes de la structure de données. Et nous avons généré les
différents glyphes SVG que nous aurons besoin. Nous avons entamé le parser.

   Au 16/03/2001, il reste un Bug dans le parser de musique, nous n'aurons pas le temps d'implémenter le
moteur de positionement, mais le SVG généré est convenable(les glyphes sont prêts)

   Nous utilisons le langage C++, pour sa rapidité, et surtout pour avoir une expérience dans ce domaine. Et
nous utilisons l’API de Xerces pour le parsing des données XML.

4.1       REPARTITION DU TRAVAIL

      Nous nous sommes réparti le travail comme suit :

      -    un responsable du parser

      -    un responsable du Layer

      -    un responsable de la génération du SVG




      François Chastanet, Antoine Paolini, François -Xavier Vila                                    15/16
SAR 6 – INTERNET                                                                           MUSIQUE-XML -> SVG



                                               5    C ON C L U S I O N


     Ce projet nous à permis d'approfondir nos connaissances en XML, SVG, C++ et nous à fait découvrir le
"parsing" XML à l'aide de l'API XERCES.

      L'autre point fort de ce projet est l'environnement SVG. En effet, pour obtenir l'affichage d'une partition,
nous sommes passés par plusieurs phases successives, où se mêlaient tour à tour des logiciels batik et Adobe
Illustrator.

     L'état actuel d'avancement de ce projet, n'aurait pas été possible sans une bonne connaissance de C++,
XML et SVG; connaissances que nous avons pu acquerir tout au long du développement. Le fait d’avoir
développé en C++ nous a certainement pris beaucoup plus de temps que si nous avions choisi Java. Mais le jeu
en valait la chandelle, nous n’aurons peu être plus jamais dans notre vie d’informaticien l’occasion de voir autant
de « segmentation fault », en fait C++ est un langage très sensible et la moindre erreur de programmation, ou
dans le fichier XML se paie au prix fort. De plus le fait d’avoir plusieurs couches logiciels ne facilite pas le
deboggage. Mais quelle satisfaction quand ça marche !
     Passionnés de musique, mélomanes, et possédant un réel intérêt pour l'informatique, ce projet nous a
particulièrement intéressé et nous comptons poursuivre son développement à l'issue de nos études.




   François Chastanet, Antoine Paolini, François -Xavier Vila                                             16/16

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:11/23/2012
language:Latin
pages:17