Projet IMA3 P7, 2016/2017, TD1 - Historique des versions

Rex : /* Partie informatique */

2017-06-21T17:22:58Z

‎Partie informatique

Rex : /* Partie informatique */

2017-06-21T17:19:14Z

‎Partie informatique

Gbontoux : /* Séance supplémentaire 7 (31/05/2017) */

2017-06-19T00:33:49Z

‎Séance supplémentaire 7 (31/05/2017)

Gbontoux : /* Séance supplémentaire (16/03/2017) */

2017-06-19T00:33:20Z

‎Séance supplémentaire (16/03/2017)

Gbontoux : /* Partie informatique */

2017-06-19T00:27:22Z

‎Partie informatique

Gbontoux : /* Séance supplémentaire (16/02/2017) */

2017-06-19T00:25:34Z

‎Séance supplémentaire (16/02/2017)

Gbontoux : Et le code, ça peut servir !

2017-06-19T00:02:09Z

Et le code, ça peut servir !

Gbontoux : Ces images sont beaucoup trop grandes

2017-06-18T23:58:31Z

Ces images sont beaucoup trop grandes

Gbontoux : Génération de sons

2017-06-18T23:56:39Z

Génération de sons

Gbontoux : Critique plus-que-pessimiste du code

2017-06-18T23:46:18Z

Critique plus-que-pessimiste du code

@@ Ligne 115 : / Ligne 115 : @@
 Le protocole de communication s'effectura comme suit :
-- Le FPGA / Arduino attend des données
+* Le FPGA / Arduino attend des données
-- Le Raspberry envoie un octet contenant l'information des LED à allumer / éteindre. Chaque bit représente une LED. Par exemple, pour allumer la LED n°1 et la LED n°3, on enverra 0b00000101.
+* Le Raspberry envoie un octet contenant l'information des LED à allumer / éteindre. Chaque bit représente une LED. Par exemple, pour allumer la LED n°1 et la LED n°3, on enverra 0b00000101.
-- Pour chaque capteur ultrason qu'il possède, l'Arduino / FPGA envoie sur un entier codé sur un octet la valeur de ce capteur
+* Pour chaque capteur ultrason qu'il possède, l'Arduino / FPGA envoie sur un entier codé sur un octet la valeur de ce capteur
-- Retour au début
+* Retour au début
 == Séance 2 ==

@@ Ligne 64 : / Ligne 64 : @@
 Chacun de ses programmes va tourner dans une boucle infini à une fréquence différente.
-   -création des sons (tend vers 44kHz) à l'aide de sinusoïde.
+*création des sons (tend vers 44kHz) à l'aide de sinusoïde.
-   -séquenceur
+*séquenceur
-     -garde en mémoire les sons qu'il va devoir jouer plus tard, cela permet d'éviter les risques de sons saccadés.)
+**garde en mémoire les sons qu'il va devoir jouer plus tard, cela permet d'éviter les risques de sons saccadés.)
-     -récupère le signal des ultrasons
+**récupère le signal des ultrasons
-     -envoi le signal aux LEDS
+**envoi le signal aux LEDS
 Récepteur Websocket : envoi à l'interface les notes jouées et reçois les notes à jouer (en mode Simon)
@@ Ligne 76 : / Ligne 76 : @@
 On va utiliser un header afin de pouvoir créer des alias et ainsi permettre de faire des ajustements du programme plus simplement (ex: si le type double est trop lourd on change dans le header l'alias plutôt que de devoir parcourir toutes les fonctions de notre programmes).
 === Partie électronique ===

@@ Ligne 254 : / Ligne 254 : @@
 [[Fichier: Maquette_SC.jpg|200px|thumb|right|Maquette et Arduino]]
-== Séance supplémentaire 7 (31/05/2017) ==
+== Séance supplémentaire (31/05/2017) ==
 Finalisation de la maquette, modifications esthétiques et câblage.

@@ Ligne 53 : / Ligne 53 : @@
 === Partie informatique ===
 [[Interface Web :]]
 Explication à tous le monde du fonctionnement de l'interface web.

← Version précédente		Version du 19 juin 2017 à 00:27
Ligne 86 :		Ligne 86 :
	Raspberry Pi : Création du programme "synthétiseur" qui permet de créer des sons, et création du lien avec la commande play du programme SoX permettant de les envoyer sur les haut-parleurs. Création d'un programme "clavier" qui permet d'envoyer des sons entrés via un clavier d'ordinateur au synthéthiseur pour tester ce dernier. Pas de gestion de plusieurs sons en même temps pour le moment, mais fonctionne en temps réel à au moins 15 ms de latence (pourra être optimisé si besoin).		Raspberry Pi : Création du programme "synthétiseur" qui permet de créer des sons, et création du lien avec la commande play du programme SoX permettant de les envoyer sur les haut-parleurs. Création d'un programme "clavier" qui permet d'envoyer des sons entrés via un clavier d'ordinateur au synthéthiseur pour tester ce dernier. Pas de gestion de plusieurs sons en même temps pour le moment, mais fonctionne en temps réel à au moins 15 ms de latence (pourra être optimisé si besoin).

		+	[[Fichier:2017_ima3_sc_td1_p7_clavier.mp4]]

	== Séance supplémentaire (20/03/2017) ==		== Séance supplémentaire (20/03/2017) ==

← Version précédente		Version du 19 juin 2017 à 00:25
Ligne 39 :		Ligne 39 :

	== Séance supplémentaire (16/02/2017) ==		== Séance supplémentaire (16/02/2017) ==
−	~~-Création de la base de l'architecture web~~
−	~~-Appels entre les pages~~
−	~~-Création des formulaires dans les différents modes disponibles (sélection des instruments et mesures de la difficulté~~

		+	- Création de la base de l'architecture web
		+
		+	- Appels entre les pages
		+
		+	- Création des formulaires dans les différents modes disponibles (sélection des instruments et mesures de la difficulté

	== Séance supplémentaire (16/03/2017) ==		== Séance supplémentaire (16/03/2017) ==

@@ Ligne 262 : / Ligne 262 : @@
 === Etat de la partie informatique ===
 Dans son ensemble le code de la partie Raspberry Pi est de qualité médiocre. En effet, en ayant voulu utiliser des pipes nommés et un script bash pour pouvoir faire un multi-threading simple s'est avéré rendre tout le système plus complexe. En effet, il a fallu implanter une logique de scrutation et de conversion des données passées. Le but recherché étant de réduire la latence, c'est probablement l'effet inverse qui a été achevé, car même si on ne la voit pas les pipes impliquent une recopie en mémoire des données transférées. Au moins on comprendra à quels problèmes les forks et des threads répondent l'année prochaine.
 De plus, certaines parties du code auraient pu être repensées, comme l'attribution d'ID aux sons et l'utilisation de liste chaînées pour éviter de parcourir un grand tableau à chaque itération et imposant par la même occasion une limite de sons simultanés. Les variable globales est aussi scandaleusement sur-utilisées. Pour que le programme fonctionne sur Raspberry Pi, on a du diviser la fréquence d’échantillonnage par deux.

@@ Ligne 174 : / Ligne 174 : @@
 On choisira donc cette dernière méthode. Pour exporter les fréquences dominantes d'un enregistrement, on va d'abord découper un court extrait de l'enregistrement et l'importer de manière à pouvoir l'exploiter. On a choisi pour cela d'utiliser Python et le module Scipy (voir fichier `rpi/instruments/analyze.ppy`).
-[[Fichier:2017_ima3_sc_td1_p7_la4piano.png]]
+[[Fichier:2017_ima3_sc_td1_p7_la4piano.png|thumb|right|400px]]
 Notre échantillon a été échantillonné à 44,1 kHz sur une durée de 0,92 secondes, on obtient donc 40572 échantillons étant des entiers codés sur 16 bits, leur amplitude va donc de -32768 à 32767. L'enregistrement étant fait en stéréo, chaque couleur correspond à un canal. On ne retiendra qu'un canal pour la suite.
@@ Ligne 180 : / Ligne 180 : @@
 On applique ensuite une transformée de Fourrier, afin d'obtenir un diagramme fréquentiel.
-[[Fichier:2017_ima3_sc_td1_p7_fourrierSimple.png]]
+[[Fichier:2017_ima3_sc_td1_p7_fourrierSimple.png|thumb|left|400px]]
 La propriété de symétrie du signal audio se reflète sur sa transformée. On ne conservera que les fréquences inférieures à 20 kHz, inaudibles pour l'oreille humaine. On remarque que la fréquence d’échantillonnage choisie par notre enregistreur numérique n'est pas anodine, en effet elle respecte le théorème de Shannon qui postule que la fréquence d’échantillonnage doit être au moins deux fois supérieure à la plus grande fréquence à capter.
@@ Ligne 186 : / Ligne 186 : @@
 On lance alors une détection de "pics" sur ce diagramme, et on conservera ceux au dessus d'un certain seuil. Il ne doit pas être trop haut pour assurer la qualité de la représentation, ni trop bas pour éviter le surplus de calcul lors de l’exécution. Pour simplifier cette détection, on a réajusté notre transformée de fourrier en utilisant une fenêtre de Hanning plutôt que rectangulaire, les pics devenant alors plus nets.
-[[Fichier:2017_ima3_sc_td1_p7_fourrierLA4.png]]
+[[Fichier:2017_ima3_sc_td1_p7_fourrierLA4.png|thumb|right|400px]]
 On exporte ces données dans un fichier `.h` généré automatiquement.

@@ Ligne 157 : / Ligne 157 : @@
 Quant à la génération du son, on pensait au début additionner les amplitudes de chaque instrument, puis diviser par le nombre d'instruments, mais le volume global de la sortie audio reste constant alors que celui des instruments individuels ne le reste pas. Il est plus naturel que lorsque l'on appuie sur deux touches en même temps, on entende une intensité doublée. On divise donc la somme des amplitudes des instruments par 5 constamment (arbitrairement). Cela permet de garantir que 5 instruments peuvent jouer simultanément sans qu'il n'y ait de saturation.
 == Séance supplémentaire (16/04/2017) ==
@@ Ligne 214 : / Ligne 252 : @@
 == Séance supplémentaire (18/06/2017) ==
 Vidéo de démonstration. Le Raspberry Pi est ici connecté à un partage de connexion via USB vers un téléphone en 4G. Le PC est connecté au réseau domestique via Wi-Fi. La communication entre les deux est assurée par un forwarding de port via SSH. Tout cela est pour démontrer que le système ne nécessite pas une connexion à grand débit ni à faible latence pour fonctionner correctement.

← Version précédente		Version du 18 juin 2017 à 23:46
Ligne 214 :		Ligne 214 :

	== Séance supplémentaire (18/06/2017) ==		== Séance supplémentaire (18/06/2017) ==
		+
		+	=== Relec


Ligne 222 :		Ligne 224 :

	== Conclusion ==		== Conclusion ==
		+
		+
		+	=== Etat de la partie informatique ===
		+	Dans son ensemble le code de la partie Raspberry Pi est de qualité médiocre. En effet, en ayant voulu utiliser des pipes nommés et un script bash pour pouvoir faire un multi-threading simple s'est avéré rendre tout le système plus complexe. En effet, il a fallu implanter une logique de scrutation et de conversion des données passées. Le but recherché étant de réduire la latence, c'est probablement l'effet inverse qui a été achevé, car même si on ne la voit pas les pipes impliquent une recopie en mémoire des données transférées. Au moins on comprendra à quels problèmes les forks et des threads répondent l'année prochaine.
		+	De plus, certaines parties du code auraient pu être repensées, comme l'attribution d'ID aux sons et l'utilisation de liste chaînées pour éviter de parcourir un grand tableau à chaque itération et imposant par la même occasion une limite de sons simultanés. Les variable globales est aussi scandaleusement sur-utilisées. Pour que le programme fonctionne sur Raspberry Pi, on a du diviser la fréquence d’échantillonnage par deux.
		+	Il en va de même pour le code Javascript côté navigateur.
		+	Dans le même ordre d'idée il manque de commentaires et d'explications, de rigueur dans les conventions...
		+	Mais les deux choses les plus importantes sont que le programme fonctionne, et que l'on a su reconnaître nos erreurs pour ne pas les refaire dans le futur.