Version du 7 mars 2016 à 14:27

Interaction avec l'encadrant

<Déposez ici vos remarques et commentaires>
<Précisez, s'il vous plaît la date et l'auteur du message>

Cahier des charges

Présentation générale du projet

Le projet s'inscrit dans la démarche artistique de M. Lucas PRIEUX, artiste marionnettiste. Son souhait est de montrer ce que les nouvelles technologies d'aujourd'hui nous apportent.
Le dossier de création de la pièce HUMAINS est disponible ici [[1]]

Objectif du projet

L'objectif final du projet est de créer un dispositif comprenant une entrée MIDI (standard pour le son), et des sorties sur lesquelles on brancherait des instruments électroniques du type scanner ou lecteur de disquettes.

Description du projet

Le projet se divise donc en différentes étapes :
- La première étape est de bien définir le cahier des charges avec l'artiste afin de connaître ses attentes sur ce projet
- la seconde étape va être de mettre en place un dispositif (Raspberry Pi) permettant de décoder la trame MIDI reçu sur l'entrée et d'afficher les notes jouées par les instruments
- la dernière étape s'appuiera sur les volontés de l'artiste et des encadrants.

Choix techniques : matériel et logiciel

Matériel nécessaire :

• Raspberry Pi
• Adaptateurs USB-MIDI avec 1 USB et 2 sorties MIDI_IN et MIDI_OUT disponible chez LDLC [[2]]
• Instruments électroniques: du vieux matériel disponible ici en occasion pour pas cher:[[3]]
  
  • Lecteurs de disquettes
  (vieux lecteurs disponibles au fabricarium)
  • Disque dur
  (fabricarium peut-être)
  • Imprimante matricielle
  • Modem 56k
  • Magnétoscope
  • Lecteurs CD/ROM
  (fabricarium toujours)

Calendrier prévisionnel

Avancement du Projet

Préparation du projet : Mise en place du cahier des charges

2/11/15 : Réunion avec les différents acteurs du projet afin de bien fixer les attentes, les volontés de ces derniers.
C'est également lors de cette réunion que l'on fixera le cahier des charges et le matériel nécessaire
Résumé de la réunion :
L'objectif de cette réunion était de fixer les attentes et les volontés du porteur du projet.
Dans un premier temps, nous avons discutés avec M.PRIEUX du contexte dans lequel était inséré ce projet.
Ensuite, nous avons discutés des fonctionnalités du dispositif. Nous lui avons soumis 2 idées :

• Soit jouer en direct sur les instruments électroniques ce qui est joué sur un clavier
• Soit pré-enregistrer une séquence d'instruments électroniques et de la re-jouer au moment voulu

M.PRIEUX a souhaité que ces 2 fonctionnalités soient intégrés au dispositif.

Il a également été question du coeur de notre dispositif. Nous nous sommes tous dit que si l'on utilisait un Arduino, il aurait été obligatoire d'ajouter en plus une Raspberry Pi pour y intégrer le logiciel. Nous avons donc conclus qu'utiliser une Raspberry Pi serait mieux pour éviter l'encombrement et pour disposer de plus de fonctionnalités.
Concernant la RP, une distribution Linux spécialisé pour le traitement du son a été évoqué.

Il a aussi été demandé d'étudier la plage de fréquences des différents appareils afin de répartir les notes sur les instruments.

Cahier des charges :
Le dispositif est donc composé de :

• Une entrée MIDI afin de brancher un clavier
• Une Raspberry Pi afin de déterminer les canaux MIDI et de réaliser l'interface Web
• Une sortie MIDI pour venir y brancher un synthétiseur de son MIDI afin de synthétiser les sons impossibles à jouer avec les instruments électroniques (possibilité de mise en place d'une deuxième RP muni du logiciel Rosegarden [[4]]
• Une carte électronique permettant de venir brancher les différents instruments électroniques

Notre dispositif devra donc avoir 2 fonctionnalités :

• Une première fonctionnalité sera de jouer en direct les notes sortant d'un clavier MIDI
• Une deuxième fonctionnalité sera de pré-enregistrer une séquence d'instruments électroniques et de la rejouer au moment voulu

Un petit schéma résumé s'impose :

Sons disponibles avec tout notre matériel :

Ici, un très joli bruit caractéristique d'un modem 56k (Ah, la nostalgie ...) : [[5]]
La, un très bon morceau joué sur lecteur de disquette : [[6]]
Et maintenant, l'impression (on dirait les machines à tickets de caisses ...) avec une imprimante matricielle : [[7]]
Le tout mis en oeuvre : [[8]]

Semaine 1

25/01/16 :

• Réception du matériel (disques dur, lecteurs de disquette, lecteurs CD, scanner et imprimantes)
• Découverte du fonctionnement des lecteurs de disquettes (brochage, pins à utiliser pour piloter le moteur)

27/01/2016 :

• Découverte de la programmation des GPIO sur la RPi avec Python (bibliothèque RPi.GPIO)
• Toujours avec Python, nous réussissons à faire vibrer le moteur du lecteur de disquette (en utilisant une PWM et en contrôlant les bonnes broches du floppy disk)
  Dans une boucle conditionné par des exceptions (try/catch), nous faisons vibrer pendant un certain temps le moteur à des fréquences différentes, en utilisant alternativement les méthodes ChangeFrequency sur l'objet représentant la PWM (p.ChangeFrequency(220) par exemple), et en utilisant la bibliothèque time et la méthode sleep (time.sleep(<durée de la note>))
  
• Programme pouvant "approximativement" jouer la marche impériale (Star Wars). Petites photos :
  
  
  
  
  
  
  

Semaine 2

01/02/2016 :

• Amélioration du programme permettant de jouer la marche impériale (utilisation de 2 tableaux : un contenant la fréquence des notes à jouer, et l'autre contenant la durée des notes)

03/02/2016 :

• Début d'écriture d'un programme Python permettant de décoder un fichier MIDI --> Conclusion : Utilisation d'une bibliothèque au lieu de tout faire à la main
• Test sur l'imprimante à aiguilles pour piloter le moteur --> SANS SUCCES (Communication série ?)

04/06/2016 :

• Écriture du programme communiquant avec l'imprimante a aiguilles en série avec la RPi (langage de description de page (PDL) Epson ESC/P2 pour envoyer les commandes en série à l'imprimante)

Semaine 3

10/02/2016 :

• Fin d'écriture du programme traitant le fichier MIDI : en sortie, on obtient 3 tableaux : 1 contenant les notes, 1 contenant la hauteur des notes, et 1 contenant les ticks (date d'apparition de chaque événement). Ces tableaux nous serviront à gérer les GPIO pour les disques durs et les disquettes.
• Test sur le disque dur : vibration de la tête de lecture (juste grâce à une alim pour voir si la tête vibrait)

11/02/2016 :

• Transformation d'un disque dur en instrument électronique : vibration de la tête de lecture grâce à une PWM
  Fichier:DD0742.mp4
  Inconvénient : Bruit très faible --> Besoin d'une caisse de résonance afin d'améliorer le son provenant de la tête de lecture (à étudier)

Semaine 4

24/02/2016 :

• Tentative de communication avec le port série sur l'imprimante à aiguilles --> Toujours sans succès ...
• Au lieu d'utiliser la bibliothèque interne de la RPi pour gérer la PWM et les GPIO, nous utiliserons la bibliothèque WiringPi. Elle offre plus de fonctionnalités que la bibliothèque de base
• Début du codage de l'interface WEB :
  
  • Choix du serveur WEB : lighttpd : Pourquoi ? Tout simplement car il est beaucoup plus léger qu'un serveur Apache et qu'il est plus adapté pour les processeurs ARM dont dispose la RPi
  • Interfaçage entre les scripts Python et Web : CGI (Common Gateway Interface).
  • Architecture du serveur WEB et explications :
    
    

    Explications : Le serveur lighttpd prend sa racine dans le répertoire /var/www de la RPi. On dispose de 2 répertoires : html afin de stocker les pages WEB et cgi-bin afin de stocker les scripts destinés à être exécuté.
    

    Lorsque la page WEB demande l'exécution d'un script, ce dernier passe dans l'interpréteur contenu dans le serveur CGI, et le résultat est retourné vers la page WEB.
    

27/02/2016 (et oui, même le week-end, on bosse !)  :
Grâce au matériel que l'on a chez nous, nous arrivons quand même à travailler sur l'interface WEB.

• Problèmes rencontrés avec le codage d'un script pour découvrir wiringPi et CGI (utilisation d'une PWM pour faire tourner un servo-moteur):
  • Problème avec les autorisations de l'utilisateur www-data du serveur : les scripts python (notamment ceux avec wiringPi) doivent s'exécuter en root pour pouvoir manipuler les GPIO.
    Solution : Modifier le fichier /etc/sudoers afin que les scripts exécutés sous l'utilisateur www-data (serveur) puissent d'exécuter sans demander de mot de passe lors du passage à l'utilisateur root. Et l'exécution des scripts python se fera par du php par la commande exec(sudo <chemin/script_python>)

Semaine 5

29/02/2016 :

• Configuration de la Raspberry Pi pour aller sur internet, installer et mettre à jour les paquets (modification du fichier apt.conf)
• Installation des différents paquets pour nous permettre de créer le serveur web et de faire tourner le serveur CGI (Paquets installés : lighttpd, fastcgi, php5-cgi, python-dev et python-pip)
• Utilisation de l'utilitaire PIP pour installer la bibliothèque WiringPi2 (utilisation d'un script shell afin de passer le proxy dans la commande)
• Configuration du serveur lighttpd (modules à utiliser, prise en compte du serveur cgi et de l'exécution de scripts python et php)

02/03/2016 :

• Test du bon fonctionnement du serveur web lighttpd (test avec une page html, et une page php)
• Test du bon fonctionnement de la bibliothèque WiringPi2 et du serveur CGI avec un petit script qui fait clignoter une LED 5 fois (utilité --> Nécessaire pour piloter 1 instrument seul)
• Dans la perspective de contrôler plusieurs instruments en même temps, mise en place de threads afin de faire clignoter 3 LEDS en parallèle (utilisation de la bibliothèque threading de python, redéfinition du constructeur du thread __init__ et redéfinition de la méthode run (code que va exécuter le thread) --> Vidéo à venir
• Problème : WiringPi ne gère que des PWM soft et ne gère pas les successions d'écriture. C'est donc inadapté à notre problème. On revient donc à la solution de départ qui est d'utiliser la bibliothèque de base de la RPi pour gérer les GPIO.
• Test d'un fichier HTML appelant un script PHP qui exécute un script python permettant de jouer la marche impériale sur 1 FDD --> SUCCES (vidéo à venir)
• Test pour gérer 2 FDD via les threads --> A poursuivre

03/03/2016 :

• Test pour gérer 2 FDD via threads --> Les 2 FDD jouent la même musique (Vidéo à venir)
• Configuration de git pour passer par le proxy (script shell)
• Installation de la bibliothèque python-midi afin de gérer les fichiers MIDI
• Lorsque nous lançons le script mididump.py qui est en charge de "décortiquer" le fichier MIDI, la sortie est une (longue) liste de commandes qui sont de la forme suivante :
  
  A l'aide de notre script écrit précédemment afin de sortir les tableaux correspondant au morceau (3 tableaux :notes, vélocité, ticks), nous pourrons ainsi passer en paramètre de nos threads ces 3 tableaux, et les PWM feront le reste.
• Amélioration du premier site web avec du CSS
• Recherche sur l'interprétation des "ticks" MIDI --> Ce serait l'instant où la note est joué, cet instant étant considéré par rapport à l'évènement précédent. Une modification de notre programme qui gère les PWM est à effectuer pour pouvoir gérer ces ticks.

Semaine 6

07/06/2016 :

• Debut de l'association entre l'interface WEB, le programme python qui traite les fichiers MIDI, et les instruments
  
  • Interprétation des ticks MIDI : Modification du programme en conséquence
  • Création d'une association entre les numéros de notes et les fréquences de ces dernières : utilisation d'une table d'association clé-valeur <K,V>
    
    • K : clé qui représente le numéro de la note
    • V : Fréquence associée à la note K

Liens

floppy drive music
Disk organ

Fichiers Rendus

Tous les codes sont présents dans notre GIT
https://archives.plil.fr/troj/IMA4_S8_P45