IMA4 2016/2017 P19 : Différence entre versions

Version actuelle datée du 15 juin 2017 à 06:29

Cahier des charges

Discussion du 09/12/16 avec M Redon :

• Contrôle des lecteurs disquettes et HDD fonctionnel
• Revoir la régulation de l'imprimante matricielle : potentiellement juste effectuer des tests "réponse à une entrée" pour établir la fonction de transfert de l'imprimante
• Réussir à "faire croire" aux modems qu'ils communiquent via un serveur vocal : explorer la piste du module Pluscom skype/pstn gateway
• Approfondir l'analyse des fichiers MIDI
• Éventuellement chercher d'autres instruments !

Discussion du 26/01/17 avec M Roj :

• Reprendre la configuration matérielle initialement choisie, à savoir :
  • Une RPI servant à rediriger le flux MIDI selon chaque canal (instrument)
  • Une arduino UNO en amont de chaque canal transcrivant le flux MIDI en données propre à chaque instrument
• Récupération d'un fichier MIDI opérationnelle mais adapter le code au clavier de M Prieux
• Caractériser l'imprimante matricielle
• Amplification du son produit par les HDDs

Présentation générale du projet

Contexte

Pour ce projet nous reprendrons celui de l'an passé. Il s'agira de finir les tâches entamées et d'en commencer de nouvelles afin de fournir à l'artiste Lucas Prieux, un orchestre électronique fonctionnel et répondant à ses souhaits afin qu'il puisse assurer son spectacle Humains dans des conditions idéales.

Description du projet

Ce projet consiste à mettre au point un orchestre électronique, c'est à dire utiliser des appareils obsolètes tels qu'une imprimante matricielle, des disques durs, lecteurs de disques, scanners, modems,... afin de produire des sons joués par l'artiste via un clavier MIDI et de mettre au point une interface WEB afin de gérer les instruments déployés.

Objectif du projet

L'objectif est de compléter le travail effectuer l'an passé par nos camarades, il se divise en deux grandes parties :

• Électronique : commander l'imprimante matricielle et les modems.
• Informatique : analyser un fichier MIDI afin de générer la commande de nos divers instruments.

Choix techniques : matériel et logiciel

Nous reprendrons le matériel utilisé par le groupe de l'an dernier, à savoir :

• Raspberry Pi
• Des adaptateurs USB-MIDI avec 1 USB et 2 sorties MIDI_IN et MIDI_OUT
• Instruments électroniques:
  
  • Lecteurs de disquettes
  • Disque dur
  • Imprimante matricielle
  • Modem 56k
  • Magnétoscope
  • Lecteurs CD/ROM
  • Scanner
  • Clavier MIDI

Calendrier prévisionnel

Liste des tâches à effectuer

Dans un premier temps nous souhaitons :

• Analyser un fichier MIDI, afin de pouvoir traiter les données envoyées par le clavier MIDI et générer une commande adaptée à chaque instrument
• Récupération du fichier
• Isoler les informations utiles
• Traiter ces informations de façon à générer une commande adaptée à chaque instrument (lecteur disquette, imprimante...)
• Commander les modems 56k
• Commander l'imprimante matricielle
• Commander le scanner

Calendrier

A la vue des premières recherches que nous avons effectuées et du temps nécessaire à la réalisation de chaque tâche:

• Vivian se consacrera principalement à l'analyse du fichier MIDI
• Antoine s'occupera de commander les modems et l'imprimante matricielle

Feuille d'heures

Avancement du Projet

Semaine 1 (23/01 : 27/01)

Recherche à propos de la construction d'un fichier MIDI :
jchr.be
midi.org
D'après la spécification MIDI on distingue deux principaux types de message MIDI :
Message de statut permettant de choisir :

• Une fonction : note on, note off, contrôle/change mode ...

Dans le cas d'un contrôle de note (note on/off) on peut préciser :

• Un canal(1 à 16)
• La hauteur de note (0 à 127)
• Sa vélocité (0 à 127)

Message de contrôle permettant diverses fonctions de contrôle, de modulation de note, d'effets ...
Ces données sont précédées d'une entête de 14 octets :

• 4 octets pour préciser le format du fichier (MIDI)
• 4 octets pour définir la longueur de l'entête
• 2 octets pour définir le format ( single, double track ou multiple song)
• 2 octets pour définir le nombre de pistes
• 2 octets pour définir le nombre de subdivisions découpant un temps (beat)

Chaque octet transmis est précédé d'un bit de start et suivi d'un bit de stop.

Semaine 2 (31/01 : 03/02)

• Découverte imprimante matricielle et du langage ESC/P 2
• Reprise du programme de test débuté l'an dernier

Semaine 3 (06/02 : 10/02)

• Large modification du programme de test pour l'imprimante matricielle
• Établissement d'un protocole de test afin d'identifier les paramètres influant sur le son généré

• Récupération d'un fichier midi en hexadécimal grâce à l'utilitaire shell "od -x"
  • écriture d'un script shell permettant de créer un fichier contenant uniquement les codes hexadécimaux et dans l'ordre (utilisation de sed / grep ) (qui s'avérera inutile)
• Création de programme pour récupérer les informations utiles
  • fonctions de calculs de convertion d'octets en entier, récupération d'octets, séparation d'octets, etc ( qui s'avéreront inutiles par la suite )

Semaine 4 (13/02 : 18/02)

Comparaison des fonctionnalités des imprimantes EPSON (celle utilisée est une LQ-570+) :

Mémo caractéristiques LQ-570+ :

Test du mode de commande multipoint. On teste indépendamment de faire varier :

• les caractères envoyés
• le nombre de fois qu'ils sont envoyés
• la table de caractère utilisée
• écriture en mode double-strike

On perçoit (très) difficilement des variations de hauteur de note en jouant avec ces paramètres. On va alors tester le mode RLE Compressed Raster Graphics.
Test du mode Compressed Raster Graphics :

• Les sons produits sont similaires à ceux produits en mode multipoint, bien que les données (caractères à imprimer) envoyées soient différentes. Une lecture plus approfondi de chaque commande ESC/P 2 est nécessaire.

• Prise en main du clavier MIDI et de son fonctionnement grâce à l'utilitaire aseqdump.
• Début d'écriture d'un programme pour récupérer les notes du clavier à l'aide de la bibliothèque aslo/asoundlib.
  • initialisation du séquenceur : "snd_seq_open"
  • création du port : "snd_seq_create_simple_port"
  • connection sur le port : "snd_seq_connect_from"
  • lecture d'un événement : "snd_seq_event_input" qui permet d'avoir une structure " snd_seq_event " où se trouve les informations utiles
  • boucle attendant l'apparition d'un événement : "snd_seq_poll_descriptors"
  • fermeture du port : "snd_seq_close"

Rencontre avec M Prieux (18/02)

Durant cette discussion nous avons pu faire connaissance avec M Prieux et éclaircir quelques points du CDCF :

• Analyse spectrale (sonore) de chaque instrument afin que les notes jouées sur le clavier MIDI correspondent exactement à la note jouée par l'instrument en question i.e. la touche correspondant à un LA sur le clavier produira la note LA (audible)
• Associer (au moins) une octave (10 disponibles sur le clavier) à un canal MIDI i.e. à un instrument (ou à un groupe d'instruments identiques)
• Utiliser des sons percussifs, par exemple, le bruit produit lorsque le chariot de l'imprimante matricielle arrive en butée
• Le mode live sera utilisé uniquement pour la composition des morceaux, il doit donc être le plus modulable possible
• Les morceaux ainsi composés seront écrit à l'aide du logiciel Ableton et générés au format MIDI. Nous devrons donc mettre au point une procédure automatique de traduction du code MIDI afin que ce dernier soit exploitable par la RPI
• Il n'est pas nécessaire de faire un ampli de puissance pour les HDDs car le son qu'ils produisent sera capté par un micro, et mixé par le régisseur

Semaine 5 (27/02 : 03/03)

• Test du mode d'impression bit image (imprimante matricielle). Le code n'est pour l'instant pas fonctionnel, aucune réaction de l'imprimante.
• Recherche d'alternatives pour commander l'imprimante matricielle : il semblerait que la majorité des personnes arrivant à moduler le son produit par leur imprimante matricielle contrôlent directement la tête d'impression à l'aide d'un circuit annexe (Arduino, RPI, FPGA...). Est-il possible de moduler le son en utilisant le langage esc/p2 sachant que nous ne pouvons ni agir sur la vitesse du chariot, ni sur la vitesse des aiguilles et ni sur la durée de leur "sortie" de la tête (on pourrait imaginer faire "racler" les aiguilles afin qu'elles vibrent).
  

Ici, un projet mettant en œuvre 12 imprimantes matricielles et utilisant les sons percussifs de ces machines (ne pas hésiter à cliquer sur les nombreux hyper-lien de ce projet).
Dans ce projet, utilisant une imprimante matricielle LQ-500, le maker a réécrit le firmware de celle-ci.

• "finition" du programme récupérant les données du clavier MIDI, il faut maintenant le relier à la RPI.
• recherches sur ableton live et les formats de fichier récupéré : il est identique à celui sur lequel on travaillait.
• Continuation du programme permettant de récupérer des informations d'un fichier MIDI en hexadecimal (pour pouvoir lire les fichiers d'ableton live)

Semaine 6 (06/03 : 10/03)

• Mode bit-image fonctionnel! Nous arrivons à obtenir des sons variables. Nous allons donc poursuivre avec ce mode.

• Recuperation du header du fichier MIDI finie
• Debut de l'écriture pour la partie "morceau" (le timing des événements est réalisé en 2 parties selon celui-ci)

Semaine 7 (13/03 : 17:/03)

• Le mode bit-image ne permet pas d'obtenir une gamme de fréquences suffisamment "large" pour pouvoir jouer des notes distinctes. Deux solutions s'offrent alors à nous pour respecter le cahier des charges :
  

Premièrement, modifier le firmware de l'imprimante sur la base de ces travaux. Cette solution serait préférable à la seconde solution (voir ci-après), mais nous ne pensons pas pouvoir répondre à la contrainte temporelle i.e. avoir une imprimante fonctionnelle au bout du projet.
Deuxièmement, employer la méthode "force brute" i.e. piloter directement le chariot et les aiguilles de l'imprimante via une carte de type RPI ou Arduino. Cela implique une dégradation de l'imprimante.

• Réécriture du programme commencé sous conseil de M. Redon (la méthode utilisé étant trop longue)

Semaine 8 (20/03 : 24/03)

• La carte SD de notre RPI2 étant corrompue, nous devons procéder à une réinstallation complète de celle-ci...

• récupération des métas-événement, sys-event et MIDI-event
• le timing entre 2 événements est maintenant traité

Semaine 9 (27/02 : 31/03)

• Réinstallation et configuration de la RPI2, incluant le serveur lighttpd et la cgi. Edition du fichier /etc/dhcpcd.conf (mémo ip) :

interface eth0
static ip_address=172.26.78.117/20
static routers=172.26.79.254
static domain_name_servers=193.48.57.34

• Pour les meta evenement (non nécessaires), il y a la longueur de l'evenement juste après sa "description", il faut donc boucler une lecture jusqu'à la fin de l'évenement.

Semaine 10 (3/04 : 7/04)

• Recherche pour pouvoir transmettre les informations du fichier de récupération des notes du clavier MIDI aux programmes des instruments :
  • dans un premier temps nous voulions mettre en place une communication inter-processus pour récupérer les événements MIDI dans notre code python de gestion des PWM. Finalement nous optons pour la création d'une bibliothèque du programme MIDI afin de l'utiliser dans les programmes en python ( déjà réalisé ). Utilisation du module Ctypes permettant d'utiliser une lib c dynamique dans un code python.

• Modification du fichier en C afin d'en faire une librairie
• Modification des fichiers Python afin d'utiliser cette librairie
  • Problèmes de "mauvaise fermeture" des programmes lancés

Semaine 11 (1/05 : 5/05)

• Utilisation des signaux en python pour pouvoir fermer les différents programmes proprement (à savoir la fermeture du port du clavier et l'arrêt des PWM sur les lecteurs disquettes)
• Nous arrivons à jouer en live avec le clavier
• Utilisation des "Events" afin de synchroniser l'exécution des notes sur les instruments en Python
• Reconfiguration du module cgi. Impossible de lancer notre programme pour jouer en live avec le contrôleur MIDI via l'interface WEB. La présence d'une boucle infinie dans notre script ne semble pas plaire à php.

Semaine 12 (8/05 : 12/05)

• Préparation soutenance

Conclusion et compte-rendu de la soutenance

Nous avons réellement aimer participer à ce projet, nous avons pu développer nos compétences techniques et mettre en œuvre ce que nous avons pu apprendre au cours de notre formation. Nous avons aussi pu découvrir et exprimer notre facette artistique. Le chemin aura été semé d'embûches mais nous avons appris à persévérer et nous savons que de futurs projets il faudra essayer d'anticiper les problèmes pour ne pas manquer de temps pour l'essentiel.
Voici les remarques qui nous ont été faites lors de notre soutenance :

• Bonne répartition des tâches, mais nous aurions du travailler sur le modem ensemble et en parallèle de nos tâches respectives.
• A propos de l'imprimante matricielle, nous nous sommes trop acharné. Une recherche des harmonies plus que des notes est à envisager, suivie d'une analyse spectrale du signal sonore.

Fichiers Rendus

Rapport de projet
Fichiers