Version du 7 mai 2019 à 10:13 (voir la source) Hleurent (discussion | contributions) (→‎Séances suplémentaires) ← Modification précédente		Version du 7 mai 2019 à 10:15 (voir la source) Hleurent (discussion | contributions) (→‎Conclusion et état du projet terminé) Modification suivante →
Ligne 476 :		Ligne 476 :
	* Trouver un microcontrôleur plus adapté et réalisant un traitement de signal plus rapide		* Trouver un microcontrôleur plus adapté et réalisant un traitement de signal plus rapide
	* Trouver un moyen de filtrer certaines notes parasites, et comprendre pourquoi certaines notes sont affichées à 2x leur fréquence réelle		* Trouver un moyen de filtrer certaines notes parasites, et comprendre pourquoi certaines notes sont affichées à 2x leur fréquence réelle
		+	* Intégrer l'amplitude du signal au message envoyé sur le port série, pour détecter quand la même note est jouée deux fois d'affilée
	* Intégrer les silences à notre partition et la notion de mesures		* Intégrer les silences à notre partition et la notion de mesures

---

Version du 7 mai 2019 à 10:15

Présentation générale

Projet : Ecriture automatique de partition musicale 

Le but de ce projet est de mettre en place un procédé de traitement de signal permettant de récupérer informatiquement les notes et rythmes jouées depuis une guitare électrique. Les données seront alors automatiquement traduites en une partition de musique.

Etudiants: Hugo LEURENT, Fabien RONCKIER

Encadrants: Alexandre Boé, Xavier Redon, Thomas Vantroys

Description

Description générale

Ce projet nous trottait dans la tête depuis quelque mois déjà, avant même notre rentrée en IMA 4. Sachant que nous aurions à réaliser un projet tout au long du S8 mettant en avant nos connaissances acquises jusqu'ici, nous avions déjà commencé à réfléchir à la direction que nous voudrions prendre. Passionnés de musique, nous avons alors eu l'idée d'associer cette passion à ce projet pour tenter d'apporter quelque chose qui pourrait s'avérer utile et faciliter la vie d'un musicien.

En tant que musicien, il est parfois bien long de réécrire une idée ou même tout un morceau sur une partition, surtout informatiquement. Des logiciels existent pour cela, mais la plupart sont payants. De plus, il faut bien souvent tout taper à la main, ce qui peut prendre plusieurs heures. Nous voulions avec cette idée que chacun puisse, en seulement quelques minutes, retranscrire une idée ou un morceau sur une partition rien qu'en se branchant et en jouant. Cela permettrait même à quelqu'un qui s'y connaît peu en solfège d'écrire sa partition, tout aussi rapidement que n'importe quel musicologue aguerri.

C'est alors que nous avons eu l'idée de cette partition qui s'écrirait automatiquement. Le principe serait le suivant : il suffirait de brancher sa guitare électrique à son ordinateur, de lancer le logiciel puis l'acquisition, et la partition de ce que nous jouons s'écrirait devant nos yeux. Le logiciel aurait un métronome intégré qui permettrait au musicien de jouer dans le temps pour que les rythmes soient correctement retransmis. Pour une meilleure fiabilité, nous pensions faire jouer le morceau plusieurs fois pour s'assurer de la véracité des notes et rythmes captés par l'ordinateur.

Description technique

Techniquement, ce projet pourrait être divisé en trois parties distinctes. L'intérêt est que chacune de ces parties mettent en oeuvre des connaissances apprises dans les différents modules d'IMA.

* Conception électronique :

Pour relier notre instrument (ici une guitare électrique) à l'ordinateur, nous souhaitons concevoir une carte électronique dotée d'un microcontrôleur. La carte électronique comportera une entré Jack 6.35mm, un préamplificateur (les signaux d'une guitare n'étant que de l'ordre de la dizaine de mV), la partie microcontrôleur qui réalisera la conversion analogique-numérique et le traitement du signal, et enfin une sortie USB vers le PC.

* Traitement de signal :

Cette partie s'avérera fondamentale, puisque la fiabilité de notre projet reposera sur le traitement des signaux reçus depuis notre guitare pour en extraire les bonnes notes. Il faudra alors trouver un moyen d'effacer au maximum le bruit dans nos mesures, d'effectuer des mesures de fréquences précises, mais aussi des mesures rapides pour que la partition s'écrive en temps réel. Nous devrons alors procéder à plusieurs études et tests pour trouver un compromis entre rapidité, précision des mesures et utilisation de la mémoire. Nous programmerons le microcontrôleur (certainement de la catégorie des STM32F4) de façon à réaliser le traitement voulu pour l'envoyer ensuite vers le PC.

* Conception logicielle :

Enfin, une partie de programmation et d’interfaçage graphique pour retranscrire les signaux reçus sur une partition. Le logiciel devra être clair et compréhensible pour un utilisateur lambda. L'utilisateur pourra régler plusieurs paramètres, comme la vitesse du métronome (donc le tempo de la musique), le nombre de temps par mesure, ou ben le nombre d'acquisitions voulues.

Objectifs

Pour obtenir quelque chose de fonctionnel à la fin du projet, nous pensons fonctionner par paliers d'objectifs à atteindre tout au long du semestre. Jusqu'à arriver, pourquoi pas, au rendu final espéré en premier lieu.

Nous commencerons par la réalisation de la carte électronique. Il nous faudra bien sûr mettre en œuvre nos connaissances théoriques pour placer au mieux les composants au service des fonctionnalités voulues. Le schematic , la réalisation du PCB et les soudures seront alors des étapes importantes à ne surtout pas négliger. Une fois cette carte réalisée, la première grosse étape aura été passée.

Nous arrivons ensuite aux parties traitement du signal et conception de l'interface graphique de la partition.

Côté traitement de signal :

Pour le traitement de signal, il faudra en premier lieu dimensionner le problème, choisir les bons paramètres d'échantillonnage et le moyen de réaliser le traitement. Nous pensons partir sur un STM32F4, microcontrôleur ayant largement les capacités de réaliser ce que nous souhaitons.

Pour tester le bon fonctionnement de notre traitement de signal, nous pensons également le faire par étapes :

• Dans un premier lieu, tester sur un enregistrement en .wav ou .mp3 déja existant, et sur une seule note. Cela permettra d'ignorer les bruit générés lors de l'acquisition.
• Prendre ensuite en compte le bruit généré par la carte électronique et les micros de la guitare et adapter le traitement en fonction.
• Vérifier que les fréquences sont correctement reconnues et qu'on se rapproche assez de la note voulue. Toujours en n'étudiant qu'une seule note et non tout un morceau.
• Enfin, étudier la partie temps réel de l'acquisition en traitant le morceau dans son ensemble, pour obtenir au final des fréquences en fonction du temps.

Côté conception logicielle :

Après avoir choisi le langage de programmation adéquat, il serait plus judicieux de créer un premier programme plus simple, pour se familiariser avec le langage et les outils d'interfaçage graphique.

Un accordeur de guitare pourrait être un bon début. Il suffirait de capter la fréquence d'une note jouée (d'abord depuis un enregistrement puis ensuite de notre guitare lorsque nous aurons réalisé la partie TS). Le logiciel afficherait la note la plus proche et si la fréquence est trop haute ou trop basse.

Une fois plus à l'aise avec ces outils, il devrait être plus abordable de créer notre fameux outil d'écriture automatique de partition.

Reste à voir jusqu'où nous pourrons arriver dans ce projet, le but étant en fin de S8 d'avoir un outil fonctionnel et présentable, quitte à devoir repenser nos plans prévus à la base si nous faisons face à des imprévus.

Analyse du projet

Positionnement par rapport à l'existant

Il existe de nombreux logiciels d'écriture de partition (Guitar Pro, Musescore... ), mais très peu ont la capacité de l'écrire automatiquement directement depuis un instrument. Tous ces logiciels ne permettent que l'écriture à la main d'une partition, et notre projet pourrait alors s'avérer une fonctionnalité bonus pour ce genre de logiciels.

Un principe se rapprochant du projet que nous souhaitons accomplir serait celui de Rocksmith. Ce jeu video utilise un câble qui relie notre guitare au pc pour comprendre les notes et accords jouées par l'utilisateur. Nous pourrions nous inspirer de son système de fonctionnement pour notre projet.

Honnêtement, nous ne pensions pas qu'il existait déjà un système capable de reconnaître les notes et de les retranscrire comme nous souhaitons le faire. Cependant, nous sommes tombés sur AudioScore lors de nos recherches. Ce logiciel réalise exactement ce que nous souhaiterions accomplir : transcrire une partition depuis un enregistrement.

Analyse du premier concurrent

Rocksmith est un jeu vidéo développé par Ubisoft depuis 2011. A ce jour, deux opus sont sortis. La particularité de ce jeu est qu'il se joue via sa propre guitare électrique, branchée à son PC, et non une manette ou un clavier. Le PC reconnaît ensuite les notes et accords joués pour les retranscrire en temps réel sur l'écran.

Ce jeu a pour but d'apprendre la guitare aux guitaristes débutants, ou bien des morceaux plus compliqués à des guitaristes accomplis, grâce à un catalogue de morceaux pour tous les niveaux de musiciens.

Bien que le but final ne soit pas le même, le principe d'acquisition des signaux est sûrement très similaire à ce qu'on souhaite faire. Après tout, il s'agit dans les deux cas de capter, traiter et utiliser les informations d'un signal issu d'une guitare électrique pour les afficher ensuite à un utilisateur.

Nous ne considérerons pas Rocksmith comme un concurrent direct à proprement parler, mais plutôt comme une application pour les musiciens qui compléterait la nôtre : d'un côté l'apprentissage de la guitare, de l'autre côté la retranscription sur une partition. La concurrence a lieu dans la similarité d'acquisition du signal.

Pour y avoir joué personnellement, nous avons pu constater une légère latence dans ce jeu. Comme quoi même chez des professionnels, la partie temps réel du traitement de signal est un réel défi, qu'il nous faudra prendre absolument en compte.

Analyse du second concurrent

Guitar Pro est un logiciel d'écriture de partition. Bien qu'un bon nombre de logiciels de ce type existent, Guitar Pro est l'un des plus complets avec une banque de sons permettant d'écouter ses partitions, pour de multiples instruments. C'est d'ailleurs le leader du marché et un bon nombre de partitions sont aujourd'hui écrites sur GP. Il devient alors simple d'écrire et de composer dans morceaux, même sans toucher d'un instrument.

Notre projet se démarque de Guitar pro dans le sens ou nous souhaitons passer outre sa principale contrainte : devoir tout écrire à la main. Ecrire un morceau prend de longues heures sur ce logiciel.

Nous pourrions imaginer notre projet comme une fonctionnalité additionnelle de ce logiciel, qui permettrait de jouer le morceau pour écrire directement la partition sur GP. Les deux logiciels se complètent bien puisque nous pourrions imaginer écrire la grosse partie de la partition via notre projet, puis fignoler les détails sur Guitar Pro, toujours dans le but de gagner du temps sur l'écriture.

Scénario d'usage du produit ou du concept envisagé

Frank est un jeune étudiant de 20 ans. Depuis toujours, il est passionné de musique et il a même créé son groupe de rock avec trois de ses amis. Ils commencent d'ailleurs à se faire connaître dans toute leur école pour leurs reprises des plus grands groupes tels Tokyo Hotel ou même BB Brunes. Seulement voilà, Frank ne veut pas se limiter à jouer des morceaux existants, il veut aller plus loin, il veut composer ses propres morceaux. Un jour, il se décide finalement à faire le premier pas vers l'accomplissement de ce rêve. Il prend en main sa guitare, gratte quelques accords, cherche une mélodie,... Il finit par trouver un enchaînement qui lui plaît et décide de le noter à la main pour le faire partager à son groupe.

Malheureusement, notre ami Frank n'est pas très doué pour écrire des partitions et puis cela lui prend tellement de temps qu'il en perd son inspiration. Ce serait tellement plus simple pour lui si il existait une application permettant de retranscrire instantanément les notes jouées sur sa guitare. Il abandonne donc sa guitare pour partir à la recherche de ce logiciel fabuleux. Malheureusement, Frank est étudiant, il à donc peu d'argent... En voyant les prix proposés pour les logiciels de pro, Frank commence à désespérer. C'est là qu'il tombe sur la page des projets IMA4 2019, où un groupe à crée une application libre de droits permettant de faire exactement ce qu'il recherche, à savoir : retranscrire directement sur une partition les notes jouées à la guitare, et ce, simplement à l'aide d'un câble.

Frank a ainsi pu commencer à composer ses premières musiques qu'il partagea avec son groupe. Frank et son groupe ont par la suite connu un succès fou et ont même débuté une tournée à travers l'Europe en 2023.

Frank et ses amis ont ainsi suivi la route d'autres étoiles montantes de leur époque telles Grégoire ou Louane. Cependant, leur histoire s'arrête brutalement en 2032 lorsque Frank tombe dans la drogue suite à d'horribles accusations de plagiat de la part de M. Pokora. Rest In Peace Frank, tu ne seras pas oublié.

Réponse à la question difficile

- Comment faire un traitement de signal efficace avec un micro-contrôleur et une contrainte de temps forte.

Pour répondre à cette question, nous devons préciser plus en détails les paramètres d'acquisition souhaités, en comparaison de ce qui sera posible de faire via notre microcontrôleur.

Le micro-contrôleur que nous avons souhaité sélectionner est le STM3F401CB. Disposant d'un DSP (Digital Signal Processing), il est adapté pour le traitement audio. Sa clock oscille jusqu'à une fréquence de 84MHz.

La fréquence d'échantillonnage utilisée généralement en studio d'enregistrement est de 44.1kHz. Et encore, c'est pour retranscrire au mieux toutes les harmoniques du signal. Nous n'avons pas besoin d'autant de précision car nous souhaitons surtout étudier et récupérer la fréquence de la fondamentale.

Même si nous n'avons pas encore pris le temps de faire des calculs et dimensionnements précis des différents paramètres de notre traitement, on constate bien que l'horloge interne du microprocesseur n'aura aucun problème pour tenir la cadence imposée par la fréquence d'échantillonnage.

A l'échelle humaine, la contrainte de temps est moyennement forte puisqu'il est impossible de faire en dessous d'un certain seuil de notes par secondes (disons des quadruple croches (1/16è de temps) à 200 battement par minute, cela nous donne (200/60)*16 = 53 notes par secondes). Ce qui reste bien en dessous des 84 MHz de la clock. La FFT ne devrait pas avoir de mal à tenir la cadence.

- Comment gérer des instruments désaccordés ou des nuances de jeu ?

Comme notre projet nous permet de reconnaître une large gamme de notes, on peut imaginer ajouter un accordeur de guitare avant de jouer un morceau. JUstement, c'était l'étape intermédiaire que nous envisagions de créer avant de se lancer sur le logiciel de partition en lui-même. Pour s'assurer de la bonne reconnaissance des notes lors du jeu, nous ajouterons alors avant la capture une séance d'accordage obligatoire pour l'utilisateur. Il suffira simplement de comparer la note à des fréquences précises, et indiquer simplement si celle ci est accordée, trop grave, ou trop aiguë.

Une deuxième idée, au lieu de mettre en place un accordeur à chaque fois que l'on veut jouer, serait d'instaurer l'accordeur seulement lorsque le logiciel n'arrive pas à reconnaître trop de notes. L'acquisition du morceau serait alors mise en suspens tant que l'utilisateur ne s'est pas réaccordé.

En ce qui concerne les nuances de jeu, nous pourrions imaginer la mise en place d'un threshold sur l'amplitude des signaux reçus qui nous permettrait de savoir si l'utilisateur joue plutôt fort, s'il y a des crescendo, ... Nous devrons de toute façon implanter cette méthode de threshold pour reconnaître quand une nouvelle note est jouée. Par exemple pour reconnaître le rythme lorsque l'utilisateur joue plusieurs "Do" d'affilée.

Préparation du projet

Cahier des charges

Comme nous l'avons dis auparavant, le but de ce projet est de récupérer les notes et rythmes jouées depuis une guitare électrique pour les traduire en une partition de musique sur un ordinateur.

Pour cela, nous avons besoin :

1. De récupérer le signal de sortie de la guitare, via son port Jack
2. De déterminer à quelle note correspond chaque signal, via notre microprocesseur
3. D'envoyer la valeur de la note à l'ordinateur
4. Sur l'ordinateur, d'afficher chaque note sur une partition

Cahier des charges :

Fonctions	Objectif	Description	Contraintes	Niveau de priorité
Récupération du signal	Récupérer le signal de sortie de la guitare	La guitare émet un signal de sortie via son port jack, le but est donc de récupérer ce signal sur une carte électronique. Le signal devra être exploitable par la suite, il devra donc passer par un préamplificateur	Le signal récupéré doit être fidèle au signal sortant de la guitare, le bruit ne devra pas gêner son traitement par la suite	Priorité haute
Détermination des notes	Déterminer à quelle note correspond chaque signaux	Notre microprocesseur va traiter le signal pré-amplifié, le bruit va être atténué au maximum, les mesures sont ensuite faites à intervalles régulier, pour chaque signaux, ont effectue une fft afin de comparer la valeur de celle ci à la fft de notes ou d'accords connus	Chaque note doit être lue et reconnue, y compris lorsqu'une même note et joué plusieurs fois de suite, ou que le rythme augmente	Priorité très haute
Envoie des notes vers l'ordinateur	Envoyer les valeur des notes reconnues à l'ordinateur via le port série	Une fois reconnue, on envoie à intervalle régulier les valeurs de nos notes (valeur hexadécimal) sur le port série	L'envoie doit être régulier est implémenté de manière à ce que l'ordinateur reconnaisse un crescendo ou un changement de rythme	Priorité moyenne
Affichage de la partition	Afficher les notes sur une interface graphique	Le programme sur l’ordinateur associe à chaque signal arrivant du port série une note, qui sur la partition aura une position ou un forme précise	Le rythme doit être pris en compte pour retranscrire au maximum le morceau joué, et non une simple suite de note	Priorité moyenne

Choix techniques : matériel et logiciel

Choix matériels

Cette partie sera mise à jour au fil de l'avancement du projet. Dernière mise à jour le 28/01/2019
La majeure partie des matériaux dont nous aurons besoin se composera de composants électroniques. Nous aurions besoin des composants suivants :

Elements principaux :

- Le connecteur jack femelle (Amphenol ACJS-MHDR) : [1]

- L'ampli OP nécessaire à notre préampli (MAX4468EKA+T): [2]

- Le microcontrôleur STM32F411 : [3]

- Connecteur USB : []

- Filtre passe-bas (MAX7405EPA) : [4]

- Voltage regulator 5v vers 3.3V (Toshiba TCR2EF33): [5]

- Micro electret avec ampli intégré (CMA 4544 + MAX4466) : [6]

- Carte Nucleo avec STM32F411 (solution de secours au cas où notre carte ne fonctionnerait pas) : [7]

Petits composants :
Voir tableau des composants sur la page générale des projets

Choix logiciels

- Sur le microcontrôleur : Programmation en langage C, à l'aide de librairies FFT trouvables sur Internet : [8]

- Pour réaliser notre logiciel, il nous faudra en partie concevoir une interface graphique et accessible à n'importe quel utilisateur. Nous n'avons pas encore de langage défini en tête mais pensions partir vers du Python, du Java ou du C++. Il nous faudra étudier les avantages et inconvénients pour déterminer la solution optimale.

Liste des tâches à effectuer

Ce projet peut se diviser en trois parties distinctes : la conception de la carte électronique, la programmation de notre microcontrôleur et la programmation du logiciel d'affichage.

Conception de la carte :

• Choix des composantes
• Design de la carte (via Altium / Fritzing ou Designspark)
• Impression de la carte
• Soudure et tests des composants

Prévoir d'éventuels prototypes défectueux ?

Programmation du microcontrôleur STM32F4 :

• Programmation de la partie traitement du signal
• Tests (Signaux "simples" puis de plus en plus complexes)
• Programmation de la partie envoi sur port USB ou série

Programmation du logiciel d'affichage :

• Choix du code/interface
• Programmation de l'afficheur de notes
• Programmations de la réception et lecture des données du port USB ou série

Calendrier prévisionnel

On estime que la partie traitement du signal sera la plus longue. Cependant, dans ce calendrier, on a supposé qu'on travaillerait en binôme sur chaque partie. Ce calendrier représente donc plutôt les Deadlines à respecter pour chaque partie de notre projet.

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	Analyse de la partie carte électronique Question aux enseignants Création d'un premier schéma "papier" puis sur Fritzing Environ 3h	Conception du schématic sur Altium Premier choix des composantes centrales de la carte 4h	Terminer la conception de la première version schématic sur Altium Avancer sur la liste du matériel 4h

Prologue

Avant de commencer notre projet, nous avons contacté Mr Boé pour éclaircir certains points à propos de la partie électronique.

Nous avons discuté une bonne heure pour qu'il puisse répondre à nos questions, nous permettre de trouver un point de départ et nous expliquer plus en détails l'intérêt des différentes pattes du microcontrôleur.

On a ainsi pu mettre en place un schéma "initial" présentant les différents composants qui nous seront utiles pour la conception. On nous a notamment conseillé de concevoir la carte de manière à pouvoir la déboguer facilement, et également de prévoir plusieurs alternative au signal d'entrée (prise Jack ou micro) et de sortie (USB ou port série). Nous avons envisagé la possibilité de modifier facilement les résistances, pour éviter de dé-souder et re-souder par dessus, ce qui pourrait à la longue endommager notre circuit. Cette possibilité de disposer "d'alternatives" à notre circuit nous fait peut-être perdre du temps de routage et de la place sur notre carte, mais nous facilitera grandement la tâche en cas de "défauts" dans le traitement des signaux.

Semaine 1

Lors de cette première semaine, nous avons commencé à créer le schematics de notre carte électronique. Chez nous, nous avions déjà réfléchi à certains choix de composantes (microcontrôleur, filtre, alimentation,...) mais nous l'avions implémenté sur Fritzing car beaucoup de nos composants étaient déjà présents dans la bibliothèque de base. Finalement, lors de cette séance, sous avons commencé à travailler sur Altium. Nous avons donc mis une bonne partie du temps à recopier ce que nous avions fait et surtout à récupérer les librairies des composants manquants

Nous avons commencé par importer des bibliothèques correspondant à nos composantes connues actuellement, soit :

• Un microcontrôleur STM32F411RET6 [9]
• Un micro electret [10]
• Un filtre passe-bas MAX7401ESA+ [11]
• Un amplificateur OPA344UA
• Une prise jack femelle 6.35 mm

Nous avons ainsi commencé à placer les composants autour de notre microcontrôleur, en commençant par l’alimentions via le port USB, le boot0, le reset, les leds test et le débug, et nous avons fini par l'amplificateur d'entrée, placé après les entrées micro et/ou jack.

En amont de cet ampli nous placerons le micro et la prise Jack (à connecter par la suite au choix grâce à des fils), puis en aval, nous placerons le filtre. Il nous reste également à placer le quartz (p84 datasheet).

Semaine 2

Lors de cette séance, nous avons essayé de compléter une première version de notre carte électronique, à savoir ajouter un micro et une prise jack, choisir les composantes pour un filtre adéquat, et terminer la partie communication avec un ordinateur via USB, en ajoutant une ATMega16u2.

Contrairement à ce que nous pensions faire la semaine précédente, nous avons décidé de partir sur un micro avec ampli intégré (voir liste des composantes). Désormais, lors du câblage de la carte, nous pourrons choisir de passer soit par le micro, puis un filtre, soit par la prise jack + ampli avant de passer par ce même filtre.

En fin de séance, nous avons parler de la possibilité d'utilisé un shield pour passer outre notre STM32 dans l'éventualité où celle-ci ne fonctionnerait pas.

Semaines 3, 4 et 5

Ces trois semaines, nous avons continué à avancer sur la schematic de notre projet. Nous regroupons ces trois séances ici car elles ont toutes consisté à améliorer le schematic jusqu'à en avoir une version 1, que nous allons expliquer ici. Nous avons pu dans un premier temps simplifier notre schematic en constatant que notre STM32 disposait déjà d'un moyen de communication directe en USB. Par conséquent, plus besoin du 16u2 pour passer d'une connexion série à USB. Nous avons également dû mettre à jour des symboles et footprints récupérés sur Internet qui ne correspondent pas forcément avec les traces réelles du composant. Nous avons également modifié certains composants, en fonction des stockes dont disposait l'école. Nous avons changé de voltage regulator par exemple, mais surtout notre microcontrôleur est maintenant un STM32L433CCT6. Pour l'usage que nous souhaitons en faire, il n'a pas de différence fondamentale avec le STM32F411 envisagé de base. Bien que les séries F soient plus orientées traitement du signal, et les séries L plus orientées ultra-basse consommation, nous ne comptions pas utiliser le F411 à son plein potentiel.

Notre schematic se compose alors de deux grandes parties : Le microcontrôleur et ce qui l'entoure, et de l'autre côté la partie entrées, amplification et filtrage du signal. En plus de cela, une partie notre schematic est constituée de headers auquel nous relions certains signaux de notre carte, qui serviront à éventuellement convertir notre carte en shield pour passer outre ce microcontrôleur si celui-ci ne fonctionne pas.

Concernant le microcontrôleur :

Une bonne partie concerne l'alimentation. La partie du haut gère la régulation de 5V à 3.3V entre le port USB et le reste du circuit. Sur le microcontrôleur en lui-même, les ports VDD sont reliés comme nous le conseille la datasheet pour gérer l'alimentation. Le Reset et la Clock sont également reliés selon les conseils de la datasheet. Nous avons consacré 4 pin à diverses LED pour avoir une information visuelle du fonctionnement ou non de nos programmes. Le port PA0 est relié au reste du circuit, c'est lui qui récupèrera l'information générée par nos signaux. C'est un header auquel on pourra relier un signal d'entrée, pour faire divers essais. On a une sortie nommée clk_filter qui est reliée à notre filtre passe-bas pour générer une clock synchrone avec ce dernier. Les autres pin seront reliés à des header, au cas où il nous faudrait leur brancher quelque chose. Cela nous permettra plus de flexibilité lors de nos tests.

Concernant les entrées :

Plusieurs parties sont visibles ici. Beaucoup sont reliées à des header, pour ensuite pouvoir choisir quel composant brancher auquel. D'abord on a un header 3 broches pour y brancher notre microphone + ampli intégré. Ensuite nous avons la prise Jack, dont les sorties sont reliées à un système d'amplification du signal. Ce dernier sort sur un header, que l'on pourra ensuite relier directement au microcontrôleur ou bien faire passer dans un filtre passe-bas à 5 kHz (comme la fréquence la plus haute de notre guitare devrait être vers 1.3kHz, nous pourrons faire en sorte d'éliminer le plus d'harmoniques possibles).

Pause de Février

Pendant les vacances de Février, nous avons commencé à nous renseigner sur les futures parties du projet. Une Nucleo avec F401 nous a été prêtée afin d'appréhender la partie microcontrôleur qui, pour rappel, devra traiter le signal pour en renvoyer une donnée exploitable par le PC. La programmation sur cette carte étant assez différente et plus compliquée qu'une programmation Arduino par exemple, ce qui ne nous a pas facilité la compréhension. De plus, les sources sont plus limitées sur Internet, et proposent beaucoup de façons différentes de programmer sa carte (via STM32Cube, MBed, µVision...). Après quelques heures de recherches et des essais assez peu fructueux, nous avons décidé d'attendre un rendez-vous avec un tuteur pour éclaircir ce point et continuer nos recherches de ce côté.

Par contre, nous avons donc essayé d'avancer sur l'interface graphique de notre logiciel. Même sans avoir de signal d'entrée traité, nous pouvons déjà commencer à appréhender l'interface graphique et décider du langage à utiliser. Nous avons donc décidé d'utiliser le langage Java. Disposant de larges ressources bien documentées (awt et swing), nous pouvons profiter des cours de Java dispensés en SC pour utiliser nos bases et améliorer nos connaissances dans le langage. De plus, une grande communauté et beaucoup d'exemples, de librairies et de tutoriels sont disponibles sur internet, ce qui facilite la tâche.

Pour commencer à prendre en main le fonctionnement de l'interface graphique, nous avons alors décidé de réaliser un programme qui n'est pas le sujet principal de notre projet mais qui devra quand même y figurer : un métronome. Cela nous permet de ne pas travailler avec un signal d'entrée pour l'instant, et de concevoir le premier outil utile à notre logiciel. En effet, l'utilisateur devra forcément travailler avec un métronome car le tempo est très important dans ce projet : il faut que le logiciel sache le tempo choisi par l'utilisateur pour renvoyer ensuite les bonnes notes au bon rythme. De plus, il faut que l'utilisateur ait toujours une base rythmique sous les yeux et/ou dans ses oreilles pour ne pas perdre le rythme au cours de l'enregistrement de son morceau.

Nous avons donc commencé la réalisation d'une fenêtre de métronome, qui indiquerait des cercles de couleur (rouge pour le premier temps, orange pour les autres), et pourquoi pas un signal sonore, en fonction d'un BPM et d'un nombre de temps par mesures choisis. Pour l'instant tout ne fonctionne par parfaitement mais nous avons donc profité des vacances pour débuter cette partie-ci du projet. Nous attendons un rendez-vous avec un tuteur pour valider notre schematic et répondre à nos diverses questions concernant la programmation de la Nucleo.

Semaine 6

Cette semaine, nous avons pris un temps afin de compléter notre Wiki avec plus de détails et de photos, car il ne l'avait pas été depuis quelques semaines. De plus, nous avons fait valider une bonne fois pour toutes notre schematic auprès de Mr.Boé pour débuter la réalisation du PCB.

Nous avons également récupéré des renseignements sur la programmation sur Nucleo, mbed et les différentes sources qui pourraient nous être utiles lors de la phase de programmation à venir. Nous y voyons maintenant plus clair et pourrons débuter l'approche de la réalisation des fonctions voulues au cours des prochaines séances.

Semaine 7

Et bien finalement, nous n'avions pas totalement terminé notre schematic puisque nous avons décidé, après moulte réflexions, d'y ajouter un FTDI. Après avoir dans un premier temps opté pour un 16u2 afin d'effectuer une liaison série, puis l'avoir enlevé pour privilégier l'USB, nous décidons finalement de rajouter un FTDI pour repartir sur une liaison série. La raison étant que nous nous sommes rendus compte que nous trouverions beaucoup plus de programmes documentés, d'API et d'aide si nous passions par l'UART. Ainsi, nous avons rajouté le FTDI et les bonnes connexions pour finaliser notre schematic.

Nous avons alors pu démarrer la réalisation du routage de la carte. Nous avons encore peu avancé car le schamatic a dû être modifié entre temps.

De plus, nous avons commencé à regrouper quelques parties de matériel qui nous seront utiles une fois la carte imprimée. Nous avons alors récupéré un FTDI, notre port USB, notre quartz...

D'un autre côté, nous avons commencé à établir des recherches sur ce qui avait déjà été fait dans le domaine de la musique avec des STM32, plus précisément des cartes Nucleo. De ce fait, nous pourrons dores et déjà espérer obtenir un premier prototype avant même la fin de la réalisation de la carte électronique. Quelques projets ont été repérés, notamment ce projet d'accordeur : [[12]].

Il suffit de remplacer l'envoi des données vers l'écran par un envoi vers l'UART pour récupérer les données traitées sur le PC. Des fonctions semblent avoir déjà été réalisées et un traitement du signal effectué, qui correspond à ce qu'on voudrait également faire.

Nous nous sommes alors dits que nous pourrions, avant de concevoir entièrement le logiciel de partition, partir sur l'idée de cet accordeur puis dans un deuxième temps si nous avons le temps, réaliser l'écriture d'une partition. La séance touchant à sa fin, nous nous sommes alors fixés les objectifs pour la séance à venir : d'un côté terminer le routage du PCB, de l'autre démarrer la réalisation de l'application d'accordeur, maintenant que nous avons acquis des bases en Interface Graphique via Java.

Semaine 8

Le schematic terminé, nous entamons d'un côté le routage de la carte pour pouvoir l'imprimer et la souder au plus vite.

De l'autre côté, nous nous sommes attelés à la réalisation de la partie logiciel de notre futur accordeur. Via Java, nous avons réalisé un programme qui, à partir des 12 notes de musique et de la fréquence de base d'un DO de 32.7 Hz, détecte de quelle note se rapproche le plus une fréquence d'entrée. Pour l'instant nous simulons notre fréquence d'entrée via un terminal. Comme la suite de fréquences d'une note correspond à une suite géométrique, nous n'avons besoin que d'une fréquence correspondant à une note de référence pour obtenir les suivantes.

Nous avons ensuite commencé la réalisation de la partie graphique, mais il nous reste encore quelques ajustements avant d'obtenir un affichage digne de ce nom, pusqu'il nous faut appréhender de nouveaux éléments pas forcément vus en cours.

Semaine 9

Cette semaine, après une vérification faite par Mr.Boé et Mr.Flamant, nous modifions notre PCB pour l'adapter aux remarques. Il devrait être prêt, nous l'espérons, la semaine prochaine.

En parallèle, nous décidons de réaliser notre système d'amplification du signal de guitare sur breadboard pour ensuite envoyer ce signal vers la Nucleo, histoire d'avoir une solution de secours en cas de non fonctionnement de la carte. Pour rappel, nous avions trouvé ce lien [[13]] au cours de la semaine 7 qui consistait en un projet d'accordeur sur Nucleo. Au lieu d'utiliser un écran LCD pour afficher les fréquences, nous aimerions renvoyer cette information sur le port série pour ensuite l'afficher grâce au logiciel réalisé sur PC.

Ne possédant pas d'ampli LM386 traversant, Mr.Flamant nous conseille un montage à partir d'un autre amplificateur, le TL081, rebouclé avec deux transistors bipolaires (un NPN et un PNP) pour obtenir un résultat similaire. Après obtention de tous les composants et réalisation du montage, nous essayons alors de tester la pertinence de ce circuit en branchant une guitare en entrée Jack. Nous récupèrons d'abord le signal issu de la prise jack pour en voir l'allure sur l'oscilloscope. Nous observons correctement les signaux composé de toutes les harmoniques. Cependant nous n'arrivons pas à obtenir de signal cohérent en sortie de circuit. Trop d'élements pouvant être la cause de ce dysfonctionnement (câbles, ampli, transistors ...), nous nous disons qu'il serait plus simple de commander nous-même une LM386 pour avoir moins de composants, être sûr d'avoir un ampli qui marche et pouvoir tester notre montage rapidement.

Semaine 10

Lundi

Nous avons reçu notre LM386 et procédons donc à notre montage sur Breadboard. Comme nous sommes chez nous, nous n'avons pas accès à un oscilloscope et décidons simplement de nous brancher sur un Arduino pour évaluer le signal reçu en série depuis un port analogique. Nous récupérons bien un signal à la sortie du Jack. Le problème intervient lorsqu'il s'agit de mettre notre ampli sous tension, nous constatons alors une forte présence de bruit, comme constaté sur l'image. Nous devrons rajouter une capacité et tester différentes valeurs de condensateurs pour lisser au mieux notre signal tout en n'altérant pas sa nature.

Mercredi

En arrivant en séance de projet, nous continuons ce sur quoi nous nous sommes chacun penchés depuis la semaine dernière. Fabien continue le routage du PCB et lui apporte ses dernières modifications avec l'aide de M.Flamen et M.Boé. Notre objectif est d'avoir notre carte soudée avant les vacances (donc dans une semaine et demi), donc il serait bien d'avoir notre carte validée et imprimée d'ici la fin de semaine. En fin de séance, la carte est envoyée à M.Flamen pour qu'elle puisse finalement être gravée !
De l'autre côté, nous continuons de rechercher, tester et expérimenter divers programmes pour la carte Nucleo. Notre objectif est simple : envoyer une fréquence fondamentale sur le port série lorsqu'une note d'une certaine amplitude est reconnue. Pour cela, nous nous inspirons de divers programmes, en commençant par l'accordeur trouvé il y a quelques semaines. Cependant, après de plus amples recherches, nous découvrons un programme plus simple, plus interessant et plus adapté à l'usage que nous voudrions en faire : [[14]] Ce programme réalise une simple conversion analogique-numérique, trouve la valeur d'amplitude maximale d'un signal grâce à une librairie FFT, et le renvoie via un DAC. N'ayant pas d'utilité de la partie DAC, nous pouvons en faire abstraction. Nous réalisons quelques tests qui ne s'avèrent pas particulièrement probants. Même si des fréquences nous sont parfois renvoyées, elles ne sont pas forcément cohérentes avec les résultats attendus.

Vendredi

Nous passons l'après-midi en salle C205 à réaliser des tests et notamment à faire fonctionner le montage de prise Jack-Ampli commencé Lundi sur Breadboard. Après recherche de différents montages, plusieurs essais et observations à l'oscilloscope, nous arrivons enfin en fin de séance à amplifier correctement le signal d'entrée d'une guitare (comme on peut le voir sur l'image). Nous espérons que nous pourrons donc exploiter ce signal sur notre Nucleo, en le passant par notre fonction de FFT. On constate néanmoins un certain bruit qui se retrouve amplifié et nous donne donc cette forme imparfaite (effet de larsen). En rajoutant des capacités à différents endroits du montage, nous espérons nous en débarrasser au maximum.
Des tests sont réalisés en branchant notre montage sur la carte, et nous en sortons mitigés : nous pouvons observer des valeurs de fréquences, plus hautes lorsqu'on pince une corde plus aigue, mais aucune n'est correcte. Elles semblent toutes réduire la fréquence recherchée d'un même coefficient, cela semble très étrange et nous procéderons à plus de tests pour résoudre cette affaire la semaine prochaine.

Parallèlement à cela, notre carte a été imprimée ! Elle n'a plus qu'à être soudée, au cours de la semaine prochaine.

Semaine 11

Au cours de cette "dernière" semaine d'heures de projets, nous nous sommes rendus régulièrement dans les salles de projets, quasiment tous les jours, particulièrement les salles C201 et C202. Au lieu de détailler chaque jour, détaillons plutôt l'avancement côté carte électronique, et côté programmation de la Nucleo.

Carte électronique

La carte électronique a donc été imprimée Vendredi dernier, et nous avons pu en souder les divers composants. Lundi, Mr.Flamen nous a donc montré comment souder correctement des composants CMS, en disposant la pâte à braser, les composants puis en passant la carte au four. Ensuite, Mercredi et Jeudi, nous avons continué les soudure en nous occupant particulièrement des via (pour avoir un plan de masse bien uniforme sur toute la carte), et des quelques composants traversants (prise Jack, USB, headers). Une fois cela réalisé, l'heure était venue de tester la carte, en la branchant par exemple à un PC pour voir par exemple si la LED de notre piste 3.3V s'allumait. Bizarrement, elle ne s'allume pas, bien que le PC semble reconnaître un périphérique USB branché mais ne le reconnaît pas. Nous devrons investiguer sur ce problème pour faire fonctionner notre carte électronique. Mais sachant qu'il serait compliqué de la faire fonctionner parfaitement, nous nous sommes également bien concentrés sur notre plan B : la carte Nucleo.

Programme du STM32

Comme expliqué au cours de la semaine dernière, notre programme ne nous renvoyait pas de valeurs cohérentes par rapport au signal d'entré capté par un micro ou un connecteur Jack. Nous nous sommes donc penchés dessus car il faut absolument que ce programme fonctionne pour renvoyer une fréquence exploitable vers notre PC. C'est surtout ce à quoi a été consacré notre séance de projet de Mercredi après-midi. En réalisant de multiples tests avec plusieurs versions de notre programme, nous faisions capter à notre micro un signal sinusoïdal pur pour commencer, pour voir comment le programme réagissait. Nous avons finalement compris notre erreur et essayé avec différentes fréquences d'échantillonnages pour être le plus précis possible sur les mesures de fréquences.

Le principe est qu'il stocke chaque échantillon dans un tableau de la taille de la fréquence d'échantillonnage /2 (pour partie réelle et imaginaire). Ici, nous avons pris 8192 échantillons, donc un tableau de taille 4096 qui ne garde que la partie réelle. Comme le programme que nous avions récupéré à la base ne prenait que sur 512 échantillons, nous avions oublié de modifier la taille du tableau en conséquence, ce qui expliquait nos incohérences de résultat. Ici, nous prenons une fréquence maximale de 5kHZ, car nous pouvons ainsi éliminer le plus d'harmoniques possibles et ne garder que la fréquence fondamentale. Ceci nous permet d'obtenir des résultats d'une précision de 5000/4096 = 1.22 Hz, ce qui est très correct pour l'usage que nous voulons en faire. (avec un tableau de 256 échantillons, nous n'aurions eu une précision que de 5000/256 = 19.5 Hz, ce qui est loin d'être satisfaisant. Nous ne pourrions même pas savoir si notre guitare est accordée). Pour plus d'informations, voir le programme commenté et joint en annexe.

Bon ! Notre programme renvoie enfin des valeurs cohérentes, pour les signaux purs que nous lui envoyons. Mais qu'en est-il d'un signal de guitare ? Réussit-il à reconnaître la fréquence fondamentale ? Pour constater cela, nous branchons notre montage d'amplificateur + jack de breadboard sur notre carte et... Ca ne fonctionne plus ! La valeur d'amplitude lue est complètement incohérente et les fréquences jouées ne sont pas reconnues, il persiste à nous afficher 0. Nous n'avons pas d'autre choix que de mettre ce montage de côté et de continuer nos tests avec un simple micro, qui lui fonctionne très bien.

Nous positionnons donc notre micro devant un ampli de guitare pour qu'il capte ses notes. Voici alors les résultats obtenus lorsqu'on pince chaque corde.

On peut constater des résultats probants dans l'ensemble, et on peut se réjouir que les fréquences soient en majorité reconnues, particulièrement pour les 4 cordes les plus aïgues. Pour les deux cordes les plus graves par contre, il est étonnant de constater que la fréquence reconnue est 2x supérieure à la fréquence voulue de base. Cela ne posera pas de problème s'il s'agit juste de dire que c'est un Mi ou un La, puisque ça reste la même note, mais à l'octave près. Mais cela signifie aussi que normalement sur une partition, un La à 110Hz ne sera pas du tout placé au même endroit qu'un La à 220Hz. Il nous faudra comprendre d'où vient ce problème. Il faudra également jeter un oeil aux amplitudes des signaux observés puisqu'elles ne semblent pas particulièrement cohérentes, et nous espérions les utiliser pour détecter quand une note était jouée à nouveau. De plus, les amplitudes des notes aïgues sont bien plus faibles que les notes plus graves. Enfin, on voit en noir certaines fréquences parasites très hautes, qu'il suffira de filtrer.

Pause d'Avril

Pendant les deux semaines de pause du mois d'Avril qui marquent la dernière ligne droite du projet, nous devons impérativement nous concentrer sur la partie logicielle, qui a été laissée un peu de côté pour l'instant malgré quelques essais de métronome et une première version d'accordeur. Nous voulons tester également le fonctionnement de la liaison série entre la carte Nucleo et notre programme Java sur le PC. Il faudra alors intégrer à notre programme la librairie RXTXComm et apprendre à l'utiliser correctement.

Dans un premier temps, nous chercherons à faire un accordeur de guitare bien fonctionnel, avec interface graphique et liaison série. Si nous arrivons à faire cet accordeur, nous aurons acquis de bonnes bases dans la programmation Java, la conception d'interface graphique et l'utilisation de RXTXComm. Nous pourrons ensuite intégrer ce programme à notre logiciel d'écriture de partition. Nous repartirons des programmes conçus lors de la semaine 8, pour les améliorer et implanter une GUI.

Premièrement, nous concevons l'interface graphique sans la liaison série, mais en rentrant une certaine fréquence au clavier. Le but est, quand on clique sur "acquisition", d'observer la note la plus proche, de savoir si la note est juste (écrite en verte ou en rouge), et de voir graphiquement où on se situe par rapport à la note la plus proche (sur la barre colorée dégradée, avec la flèche). On peut observer cette réalisation sur l'image à gauche. Nous avons entré une fréquence à 432 Hz, nous sommes alors désaccordés par rapport à la note la plus proche qui est le LA 440 Hz. Nous supposons que la notes est accordée si elle atteint +-2Hz de la fréquence voulue.

Ensuite, on travaille d'un autre côté sur l'implémentation de la liaison série et la récupération des données via un programme Java. Nous nous basons sur plusieurs sources qui nous apprennent à analyser les ports disponibles, à les configurer, à récupérer les informations puis les libérer. Ce site nous est notamment d'une grande aide : [[15]] (les librairies RXTX et javax.comm sont très similaires).

Nous arrivons bien à récupérer les informations concernant les fréquences sur notre terminal ! Il ne nous reste plus qu'à lier notre accordeur avec l'acquisition des fréquences en série. Cette étape nous prend bien plus de temps que ce que nous aurions imaginé puisque nous bloquons au moment de faire la liaison entre les deux classes. Comme la classe de réception série s'exécute dans une boucle, nous n'arrivons pas à en extraire la valeur de fréquence à chaque fois qu'un event DATA_AVAILABLE est provoqué. Finalement, cela à beau être un peu sale, le seul moyen que nous ayons trouvé consiste à regrouper notre classe accordeur et notre classe de récupération série dans un seul et même fichier. Là, notre accordeur marche très bien !
Réaliser cet accordeur nous a permis de prendre en main la programmation des GUI via Java, et récupérer les informations en série. Créer le logiciel de partition devrait être plus simple et plus rapide maintenant que nous avons acquis ces bases.

Enfin, nous nous occupons de créer l'interface du logiciel final, sans la partition pour l'instant. Il comprend donc l'accordeur fonctionnel, comportera également un métronome basé sur les fonctions d'il y a quelques semaines. Nous aimerions pouvoir également faire une sauvegarde de la partition une fois remplie. On peut voir à droite à quoi ressemble l'interface du logiciel.

Séances suplémentaires

Ayant bien avancé sur la programmation de la Nucleo, nous choissons d'utiliser seulement la partie son de notre carte électronique, afin de rendre un projet réellement utilisable dans les temps. Dommage pour le reste de la carte, mais nous n'aurons pas le temps de la débuguer et de faire les tests nécessaire au bon fonctionnement de sa partie microcontrôleur.

Parallèlement, nous avons imaginé un boitier à imprimer en 3D afin de rendre notre projet plus "propre". Les durées d'impression étant très longues, nous espérons pouvoir imprimer le tout à Polytech. Représentant une guitare, il abritera nos deux cartes de façon à les protéger un minimum. On peut en voir les différentes parties sur l'image de droite.

Côté logiciel, c'est la partie qui nous a pris le plus de temps et d'énergie sur cette dernière semaine de travail. Ayant toujours une partition vide en fin de vacances, il nous faut faire en sorte de la remplir. La première difficulté qui nous a bloqué un bon moment, était de savoir comment superposer deux images. Nous voulons superposer l'image de nos notes à notre partition vide afin de la remplir. Après s'être renseigné sur différentes classes, les JLayeredpane ou les ImageIcon notamment, nous avons trouvé une solution bien plus simple qui consiste à réutiliser la méthode paintComponent() de notre classe de partition. Cette petite avancée nous a pris beaucoup de temps mais nous a enfin permis de se débloquer et de pouvoir écrire des notes sur la partition.

Dans un premier temps, nous ne remplissons la partition que de noires : des notes qui correspondent à un temps, lorsque nous appuyons sur le bouton acquisition. Nous allons ensuite programmer les positions des notes sur la partition, sur une octave pour l'instant (12 notes). Nous devrons ensuite programmer plus d'octaves car pour l'instant il affichera certaines notes plus aigües que d'autres, alors qu'en réalité elles seront plus graves.

Après avoir accompli ceci, nous vérifions son bon fonctionnement avec une captation en série, et ça fonctionne ! Les notes s'affichent au bon endroit, et passent bien à la ligne suivante, c'est un bon début !

Enfin en ce dernier jour, nous implémentons les dernières fonctionnalités : la sauvegarde de la partition dans un fichier .png, l'ajout de plus de rythmes (double croche (=0.25 tps), croche (=0.5 tps), croche pointée (=0.75 tps), noire pointée (=1.5tps), blanche (=2 tps), blanche pointée(=3 tps), ronde(=4 tps)). Ensuite nous écrivons un programme de reconnaissance de la durée de la note jouée, et sélectionnons le rythme qui s'en rapproche le plus. Nous vérifions si c'est une note "normale", un dièse ou un bémol pour compléter correctement le chemin de la note et aller chercher l'image correspondante dans le dossier "img_notes". Nous travaillons avec la méthode currentTimeMillis() du package System qui permet d'obtenir le nombre de millisecondes passées depuis le 1er Janvier 1970. Nous pouvons alors déterminer le temps passé entre l'acquisition de chaque note.

Nous détectons un problème que nous n'avions pas remarqué jusque là, mais dont nous aurions dû nous douter : la vitesse de transmission des fréquences de la Nucleo au PC est trop lente avec un échantillonnage de 8192 échantillons/s. Nous recevons une note toutes les 600ms environ. C'est bien normal puisque le microcontrôleur doit pour chaque note remplir un tableau de longueur 4096 et le parcourir. C'est malheureusement le prix à payer pour recevoir une fréquence précise. Cependant, ce n'est pas une vitesse acceptable lorsqu'il s'agit d'écrire une partition en temps réel. Pour comparaison, la durée d'un temps à 100bpm (donc à tempo moyen) est de 600ms. Cela veut dire que théoriquement nous ne pourrions pas capter de rythme inférieur à la noire.

La solution trouvée est que nous allons implanter un autre programme sur la Nucleo pour l'acquisition de la partition, avec un échantillonage plus faible, donc une plus faible précision, mais un envoi plus rapide sur le port série. Nous choisissons 2048 échantillons. La précision n'est plus que de 3Hz près mais une donnée est envoyée toutes les 164ms environ. Pour accorder sa guitare, comme il est important d'être précis mais pas particulièrement rapide, nous proposons de réimplanter dans la carte programme à 8192 échantillons, qui lui a une précision de 3000/4096 = 0.73 Hz.

Les deux programmes proposés sont ajoutés à la liste des documents rendus.
Nous rajoutons également des octaves supplémentaires, pour agrémenter la partition et avoir une réelle idée de la hauteur de la note jouée. Nous pouvons ensuite sauvegarder notre programme et le compiler dans une archive JAR. Le logiciel est terminé !

Conclusion et état du projet terminé

Après avoir terminé la réalisation du logiciel et l'impression du boîtier, nous pouvons conclure sur l'état final de notre projet.
Nous avons pu au cours de ce projet travailler sur bien des aspects de la filière IMA : réalisation de carte électronique (schematic et PCB), programmation d'un microcontrôleur STM, programmation d'un logiciel sur JAVA, réalisation d'une liaison série entre les appareils... Même si notre projet est fonctionnel et atteint des résultats inespérés en début de semestre, et le cahier des charges rempli en partie, il reste des aspects à améliorer et nous en sommes conscients.

Si nous avions plus de temps, ou si nous voulions améliorer le projet dans le futur, ces points seraient à corriger :

• Tester et programmer le microcontrôleur de notre carte électronique
• Trouver un microcontrôleur plus adapté et réalisant un traitement de signal plus rapide
• Trouver un moyen de filtrer certaines notes parasites, et comprendre pourquoi certaines notes sont affichées à 2x leur fréquence réelle
• Intégrer l'amplitude du signal au message envoyé sur le port série, pour détecter quand la même note est jouée deux fois d'affilée
• Intégrer les silences à notre partition et la notion de mesures

A part ceci, notre projet est fonctionnel et il peut s'agir d'une bonne version 1.0 avant de réaliser les évolutions listées ci-dessus. Nous pensons avoir atteint les objectifs que nous nous étions fixés, même si nous avons parfois dû emprunter des chemins différents de ce que nous avions prévu (notamment l'ajout de la Nucleo).

En complément de ce Wiki, vous pourrez trouver le rapport de projet dans les documents joints. Contrairement au Wiki qui retrace notre avancée semaine après semaine, le but de ce rapport est de donner une vision plus globale des différents éléments terminés du projet.

Documents Rendus

Fichier:Carte Projet 73.PDF