Groupe LabSynth Manuel d`utilisateur du projet SynthLab

Groupe LabSynth Manuel d`utilisateur du projet SynthLab
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
Groupe LabSynth
Manuel d'utilisateur du projet SynthLab
LE CORRONC
Thibault
ZADITH
Ludovic
GUICHAOUA
Mathieu
HUVE
François
Master 2 Informatique
Spécialité Génie Logiciel
2011/2012
1/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
Table des matières
Manuel d'utilisateur du projet SynthLab..............................................................................................1
Introduction.........................................................................................................................................2
Description des modules......................................................................................................................3
Utilisation du logiciel..........................................................................................................................5
Conclusion...........................................................................................................................................8
1 Introduction
Dans le cadre du projet SynthLab, pour l'UE de Projet de groupe de Master 2 GL, nous
avons conçu une application de synthèse sonore composée de différents modules que nous
assemblons pour générer et enregistrer un signal audio.
2011/2012
2/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
2 Modèle Métier (avec aperçu de notre UI)
TYPES DE MODULES
MODULE VCO (VOLTAGE CONTROLLED OSCILLATOR)
Ce module prend en paramètre cinq valeurs : pitch, base, amplitude, attenuateur et
baseFrequence, qui influent toutes sur le signal généré. Les quatre premières valeurs sont
directement modifiables au moyen de molettes nommées selon la variable concernée (la fréquence
de base se modifie au moyen de valeurs directement entrées au clavier, pour faciliter les tests et la
présentation ; cependant, dans une version finale, elle serait paramétrée et fixée à l'instanciation de
chaque VCO).
Le type de signal émis dépend d’une stratégie que l’on peut modifier entre les trois types
que nous avons implémentées : signal carré, signal en dents de scie ou signal sinusoïdal. Les valeurs
citées plus haut sont envoyées à la stratégie, qui calcule le signal émis en fonction. Par défaut, le
signal choisi est carré.
Formule de sortie : Le signal émis est calculé selon une opération genererEchantillon,
définie dans chaque Stratégie de signal. La fréquence du signal est calculée ainsi :
(8.0/base)*baseFrequence*2.0^((pitch/12.0)+attenuateur*VFm))
et est appliquée au signal de la stratégie sélectionnée, qui évolue entre -amplitude et
amplitude quand il n'est pas modulé, et qui est écrêté entre -10 et 10 sinon.
MODULE VCF (VOLTAGE CONTROLLED FILTER)
Ce module prend en paramètre les valeurs frequenceCoupure et attenuateur, qui influent sur
le signal en entrée. La valeur de frequenceCoupure est décomposée graphiquement entre l’affinage
et la base, selon la formule frequenceCoupure = base*1000 + affinage*100 (à ce jour, l'interface
graphique propose un affichage de cette formule et des unités) .
2011/2012
3/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
Dans la stratégie Passe-Bas du filtre, cette fréquence de coupure, ainsi que la valeur lue sur
le port FM, servent à filtrer les hautes fréquences selon la formule du filtre de Butterworth, qui
laisse passer les fréquences inférieures à frequenceCoupure, et atténue les fréquences supérieures à
cette valeur.
A l'inverse, dans la stratégie Passe-Haut du filtre, cette fréquence de coupure, ainsi que la
valeur lue sur le port FM, servent à filtrer les basses fréquences selon la formule du filtre de
Butterworth, qui dans ce cas laisse passer les fréquences supérieures à frequenceCoupure, et atténue
les fréquences inférieures à cette valeur.
MODULE VCA (VOLTAGE CONTROLLED AMPLIFIER)
Ce module est paramétré par la valeur de la molette base, qui est ensuite utilisée pour
calculer l’amplification (ou l’atténuation) d’un signal obtenu dans le port IN. Le port de modulation
d'amplitude intervient également selon la formule :
VIn*base*2.0^(attenuateur*VAm)
MODULE ADSR (ATTACK, DECAY, SUSTAIN, RELEASE)
Ce module produit une enveloppe du signal selon les paramètres suivants, contrôlables à
l’aide de molettes :
-le temps d’attaque (Attack)
-le temps de décroissance (Decay)
-la valeur de maintien (Sustain)
-le temps de relâchement (Release)
La génération de l’enveloppe se déclenche quand la tension en entrée est supérieure ou égale
à une valeur palierDeclenchementGate passée en paramètre à la création du module. Sinon, le signal
émis est nul.
2011/2012
4/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
Lorsque la Gate se déclenche, et pendant la durée de son déclenchement, le signal va d'abord
monter pendant un temps AttackTime jusqu'à la valeur de tension maximum (5V) ; il va ensuite
descendre de cette tension maximum jusqu'à la tension Sustain en un temps Decay ; puis il va rester
constant à la valeur du Sustain jusqu'à la baisse de tension du signal en entrée Gate ; il va alors
entamer une baisse de la valeur Sustain à la tension nulle en un temps Release.
MODULE SPEAKER
Ce module reçoit les valeurs de tension d’un module précédent dans son port IN, les
convertit en bytes, et les transforme en un signal sonore émis sur la carte son de l’ordinateur.
MODULE RECORDER
Ce module reçoit les valeurs de tension d’un module précédent dans son port IN, les
convertit en bytes, et les enregistre dans un fichier audio nommé « enregistrementAudio.wav », afin
de pouvoir rejouer le signal émis.
NOTE : Chaque enregistrement est effectué au même endroit sur l’ordinateur ; si un
utilisateur veut effectuer plusieurs enregistrements d’un même module, il devrait déplacer
l’enregistrement précédent avant de réutiliser le module Recorder.
NOTE 2 : Certaines configurations d'ordinateurs posent un problème bloquant
l'enregistrement (exemple : les PC de l'Université). Nous supposons que cela dépend des droits
d'administration de l'utilisateur sur la machine concernée.
2011/2012
5/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
MODULE DIFFUSEUR
Ce module reçoit les valeurs de tension du module connecté à son port IN et peut les
envoyer depuis ses trois ports OUT vers d'autres modules sans aucune modification.
MODULE OSCILLOSCOPE
Ce module affiche les tensions qui entrent dans le port IN sur l'échelle [-10V, 10V] ; la
sensibilité horizontale (et donc l'échelle associée) n'est pas configurable dans notre version actuelle
(et de toute façon, elle n'aurait aucun sens, car elle serait exprimée en nombre de “valeurs” par
pixel, avec “valeur” qui dépend spécifiquement de notre implémentation :
valeur = échantillon de tension sur l'intervalle de temps 1/44100 seconde).
MODULE CLAVIER
Ce module permet de générer certaines tensions en fonction de la touche cliquée sur
l'interface du module. Ces tensions correspondent aux différentes valeurs de tons observables sur un
clavier de piano.
2011/2012
6/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
3 Plan PIM
Diagramme PIM de la version finale de la partie Abstraction de SynthLab :
2011/2012
7/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
On peut voir sur ce diagramme les relations entre les différents éléments du logiciel, tels que
nous les avons définies avant le début de la programmation :
L'abstraction du logiciel SynthLab joue le rôle d'ordonnanceur et possède plusieurs modules,
qui sont définis selon une interface commune pour permettre le transfert de données et leurs
exécutions de manière unifiée. Dans cette architecture, le transfert de données s'effectue de manière
séquentielle avec l'ordre géré par l'ordonnanceur (AbstractionLabSynth). Chaque module, lorsqu'il
est déclenché par l'ordonnanceur, effectue le traitement qu'il doit faire selon les buffers internes qui
ont été modifiés par ses ports d'entrée s'il y a lieu, puis transmet le résultat à son port de sortie qui
va le transmettre au port d'entrée relié (s'il y en a un), qui écrira dans son module propriétaire, ce qui
termine le cycle d'exécution d'un des modules, ce qui permet à l'ordonnanceur de passer au module
suivant.
Ils ont des ports d'entrée et de sortie, ayant eux aussi une InterfacePort commune. Les deux
types de port ont une fonction leur permettant de se connecter à un port de l'autre type
(connecterOut pour le port Input, et connecterIn pour le port Output).
Chaque port d'entrée garde une référence vers son module propriétaire, qui est de type
différent en fonction du nombre de ports d'entrée du module concerné. Ainsi, les instances de
AbstractionInput gardent une référence vers InterfaceModule, tandis que celles de
AbstractionInputSecondaire en gardent vers InterfaceModuleDoubleEntrees.
Dans la continuité de ce raisonnement,
InterfaceModuleDoubleEntrees étend
InterfaceModule pour proposer le premier port par héritage et un deuxième port qu'il définit luimême.
On
peut
citer
comme
exemple
InterfaceAbstractionVCF
qui
étend
InterfaceModuleDoubleEntrees, et profite donc de deux ports.
Chaque module dispose de fonctions communes (définies dans InterfaceModule) pour
configurer la fréquence, définir l'échantillon courant, et exécuter le code lié au rôle du module.
Puisque cette application était destinée à être graphique, nous avons dû transformer ce
modèle, représentant l'abstraction, en version PAC (Présentation-Abstraction-Contrôle). Voici le
diagramme réalisé :
2011/2012
8/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
2011/2012
Master 2 Génie Logiciel
Groupe LabSynth
9/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
La communication entre les éléments du logiciel se fait par la partie Contrôle du PAC, qui
transmet les appels entre les parties Présentation et Abstraction.
Pour maintenir la cohérence, les Abstractions, Contrôles et Présentations d'un module
spécifique possèdent des références entre elles à ce niveau d'héritage, et nous n'avons pas factorisé
ces liens pour ne pas permettre de configurations illégales (exemple : ControleVCA ne peut avoir
pour abstraction qu'une instance de type InterfaceAbstractionVCA, et pas de type
InterfaceAbstractionVCO).
Les ports Input et Output sont reliés par un élément Cable (non visible ici à cause de la
complexité actuelle du diagramme). Chaque contrôle de Cable possède une référence vers un
contrôle de port d'entrée et une vers un contrôle de port de sortie. Le Cable ne possède pas
d'abstraction car il ne sert pas à l'échange de données ; il est destiné à être un élément graphique, et
il sert aussi à répercuter les actions graphiques vers ses deux ports (exemple : brancher en
Drag'n'Drop le Cable d'un port vers un autre).
Certains composants possèdent une abstraction, mais ont un usage exclusivement graphique
(exemple : Oscilloscope et Clavier), et ont donc une particularité dans le diagramme de classe :
leurs abstractions connaissent leurs contrôles pour transmettre des informations.
Pour permettre aux utilisateurs de modifier certaines variables des modules, nous avons
ajouté des molettes à la partie Presentation de chaque module, qui modifient les variables
concernées en temps réel. Un type générique de molette a été créé, ainsi que des classes permettant
de communiquer entre la molette et la variable qu'elle affecte dans le module (par exemple,
« CommunicateurMoletteBaseVCA » permettant à une molette de modifier la valeur de la base dans
le module VCA, non visible sur ce diagramme).
Les molettes sont composées de :
-une classe « Molette.java » qui contient tous les éléments permettant de créer et dessiner la
molette
-une interface « InterfaceCommunicateurMolette » qui contient la déclaration des fonctions
« getCible » (pour relier la molette au module qu’elle affecte) et « execute »
-une classe nommée selon la variable affectée dans le module concerné (par exemple,
« CommunicateurMoletteBaseVCA ») qui contient le code pour les fonctions « getCible » et
« execute » (dans ce cas, les fonctions servent respectivement à lier la molette au module VCA, et à
modifier la valeur de base en appelant setBase).
2011/2012
10/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
4 Adaptation en PSM
Puisque nous avons choisi Java comme langage de développement, il y a eu certaines
particularités propres au langage, avec lesquelles nous avons dû composer. Par exemple, on ne peut
pas avoir de relation possédée par une interface : nous sommes obligés de faire en sorte que toutes
les classes concrètes héritant de l'interface propriétaire implémentent le lien vers l'interface
référencée.
Nous avons également dû imposer une librairie graphique à nos présentations de modules
par héritage (dans notre cas, Swing).
De la même façon, certaines des contraintes imposées implicitement par le diagramme de
classe PIM (une référence ayant pour multiplicité minimum 1 ne devrait pas être nulle, ou un lien
bidirectionnel devrait garantir le fait que deux entités se référencent entre elles) ne sont pas
respectées implicitement dans notre implémentation ; nous avons donc dû les forcer par codage.
2011/2012
11/12
ZADITH Ludovic
LE CORRONC Thibault
GUICHAOUA Mathieu
HUVE François
Master 2 Génie Logiciel
Groupe LabSynth
5 Conclusion
Notre architecture respecte l'aspect modulaire défini par le cahier des charges, et permet
donc de réaliser tous les branchements possibles en respectant la contrainte suivante : un câble ne
peut relier qu'un port IN à un port OUT, et notre architecture pose des contraintes suffisantes pour
qu'un développeur puisse écrire ses propres modules de manière cohérente avec le reste du logiciel.
Dans les évolutions possibles, nous proposons de paramétrer à l'instanciation la valeur de
base d'un VCO et le nombre d'octaves d'un clavier.
Il nous serait aussi possible de proposer d'effectuer des sauvegardes et des chargements de
configurations, pour pouvoir accéder à un montage sans le refaire à chaque lancement du logiciel,
en utilisant le mécanisme de sérialisation disponible en Java.
Nous pourrions également réfléchir à comment rendre le Clavier plus réactif, donc réduire la
latence globale, ce qui passerait par l'accélération de la totalité des abstractions en réimplémentant
le logiciel à l'aide de Threads.
2011/2012
12/12
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising