Architecture logicielle

Les classes mettant en œuvre la sonification sont organisées de la façon suivante :

La classe « Zone » est composée d’objets « capteur ». La mise à jour d’un capteur provoque le re-calcul de la somme des pressions de la zone correspondante. La zone peut être liée à une autre zone, c’est par ce lien qu’est obtenu l’arrêt des sons d’une zone précédente. Au moment où une zone détecte qu’elle doit déclencher un son parce que la pression a atteint un niveau fixé, elle vérifie si elle est liée à une autre zone, si c’est le cas elle appelle la méthode stopperSons() de l’autre zone. Une zone est associée à une classe « SND » (pour sound) qui est responsable de la production des sons. C’est dans cette classe que se fait la liaison avec le sous-système de production de sons. Dans le cas de cette application il s’agit de l’API JFugue qui pilote le synthétiseur MIDI, mais en associant un autre type de classe il est possible de produire les sons d’une autre manière. La classe Zone est associée aussi à l’interface « Comportement » à travers laquelle peuvent être associés différents types de comportements sonores comme le cumul ou le non-cumul de sons ou le cumul long qui n’arrête pas les sons quand la pression atteint zéro mais uniquement quand la première zone du pied suivant atteint un seuil donné. Chaque implémentation de l’interface Comportement possède une méthode verifCriteresSons() qui contient la mise en œuvre de la machine à état correspondante. La classe zone est associée enfin à l’interface « TypeSonif ». Les classes qui implémentent cette interface définissent le type de son qui sera joué : note ou accord ainsi que leur hauteur.

Quand nous parlons d’un son qui peut interrompre un son précédent, il peut s’agir du son de la zone suivante au niveau du même pied ou d’une zone du pied suivant, par exemple si l’objectif est que le son du pied gauche dure jusqu’à ce que le talon du pied droit soit posé au sol.

Figure 84 : Diagramme de classes de la partie sonification à partir des capteurs.

5.2.6.2.2 Comportement sonore

Les comportements sonores peuvent être facilement ajoutés : grâce à l’utilisation d’un design pattern77 de type « Strategy »78 (Figure 84), il suffit de créer une nouvelle classe de comportement de sons qui est l’implémentation directe d’une machine à états définissant un comportement donné. Deux exemples sont montrés en Figure 85 et Figure 86. L’ajout de nouvelles classes demande cependant une recompilation du code source.

77 _{Un patron de conception est la solution conceptuelle ou architecturale à un problème logiciel. C’est un}

recueil d’expertise en matière de conception orienté objet. Il facilite la réutilisabilité et la maintenance d’un système (Gamma, Helm, Johnson, & Vlissides, 1996)

78

Le patron de conception « stratégie » permet d’encapsuler divers algorithmes ayant des comportements différents tout en apportant la facilité d’en changer efficacement (Gamma et al., 1996)

Figure 85 : Machine à états minimale, le son de référence est joué dès que la pression est supérieure à un seuil donné. Une fois celui-ci atteint, le son référence est arrêté et le son réel est joué en tenant compte de la valeur du

pic de pression

Figure 86 : Machine à états identique à la précédente à la différence que la durée des deux sons est réglable. Chaque son est asservi à deux critères qui sont l’atteinte de la durée maxi programmée ou l’atteinte d’un seuil de pression donné

L’application permet de produire un fichier de sortie indiquant les moments auxquels sont produits les sons. C’est une fonctionnalité tout à fait nécessaire afin de vérifier que la chronologie des sons est respectée par rapport à un comportement donné79, Figure 87. Sur cette figure, correspondant à une configuration son ref./son réel (CAS 4), il est possible de visualiser 5 événements temporels ainsi que les actions associées :

1. Apparition du front descendant

2. le son référence est joué pendant 20 ms, suite à la présence de 5 valeurs décroissantes successives

3. fin du son référence. et pause pendant 20 ms 4. le son réel est joué pendant 20ms

5. fin du son ref.

Figure 87 : Détail de l'évolution des pressions sur les trois zones pour un pas. Chaque graduation des abscisses correspond à 10 ms.

La configuration des sons dans l’exemple de la Figure 88 est la suivante :

1. le son référence commence quand un seuil de pression donné est atteint 2. le son référence dure 160ms

3. le son réel commence quand le pic est détecté 4. le son réel dure 160ms.

5. Les sons s’arrêtent lorsque la pression de la zone correspondante passe à zéro

Ainsi, un comportement qui serait difficile à interpréter ou à remarquer auditivement peut être compris visuellement. La représentation graphique du fichier de sortie de notre environnement de prototypage de biofeedback sonore permet par exemple de visualiser le problème pour la zone latérale (en rouge) où il y a eu une mauvaise détection du pic (6). Parfois le son joué peut ne pas avoir la durée qui lui avait été assignée comme cela a failli

être le cas pour la zone médiale (en vert). En effet, le son réel commence quasiment à la fin du pas (7) et se termine 160ms plus tard (8) soit 40 ms avant que la pression ne passe à zéro (9). Le même phénomène aurait pu se produire si le pic descendant correspondant à la zone latérale (en rouge) avait été correctement détecté. En conséquence, la contrainte temporelle de l’accompagnement sonore est forte, le temps d'appui moyen lors de la marche normale étant de 600ms.

La présence de cette fonctionnalité donne à l’application un atout majeur en termes d’exploration sonore en permettant d’analyser et de comprendre le comportement des sons émis au-delà de ce qui est perçu auditivement.

Figure 88 : Comportement des sons différents : le son référence commence quand un seuil donné est atteint, il dure 160ms. Le son réel commence quand le pic est détecté et dure lui aussi 160ms.