Table des matières

Modules GMEM - CIRVA

hardware

Cahier des charges

Modules

Pour satisfaire aux besoins techniques de flexibilité comme aux impératifs artistique du respect de l'esthétique des modules, la structure portant les micros et transducteurs ainsi que l'électronique associée sera articulée autour d'un pied à perche de cymbale. Les câbles restent ainsi visibles et l'électronique se dévoile derrière un boîtier en plexiglas transparent.

Côté électronique chaque module est connecté à un raspberry pi qui utilise jackd pour router l'audio à faible latence, jouer des samples et gérer les ordres reçus sous forme de messages OSC. Il analyse également le signal audio entrant sur l'entrée “cv” et déclenche le solénoïde du module quand des crêtes dépassent un seuil réglable par potentiomètre. Un shield permet l'interface entre les GPIOs du pi et le mosfet de sortie du solénoïde, les entrées potentiomètres (seuil et gain de l'entrée CV) via un MCP3006 ainsi que la led RGB de l'entrée CV. L'acquisition du son et la sortie du signal audio se fait par une carte son USB Behringer U-Phoria UMC202HD équipée de préamplificateurs Midas. La sortie du transducteur passe par un amplificateur 10W à base de LM315.

Serveur

Les raspberry pi de chaque module se connectent par leur wifi à un serveur (un autre raspberry pi) configuré en point d'accès. Celui-ci héberge une interface web qui permet d'assigner à chaque module un nom, une note midi, de régler et consulter ses volumes d'entrées/sorties et de gérer ses fichiers audio. Des fichiers midis peuvent également lui être envoyés. Lorsque leur lecture est déclenchée, le serveur envoie au module concerné (assigné à cette note midi) l'ordre de déclencher son solénoïde pour une durée proportionnelle à la vélocité de la note.

Software :

Cahier des charges :

Implémentation

Le code implémentant ce cahier des charges est accessible sur Github. Il est principalement rédigé en Python3 pour rester facilement modifiable.

Modules : côté client

Chaque instrument de verre est associé à un raspberry pi contenant le code client qui est automatiquement lançé au démarrage.

solénoïde

Le solénoïde est contrôlé par le module solenoid.py du dossier client, la librairie Rpi.GPIO permet de commander le mosfet et des précautions ont été prises pour éviter un déclenchement trop long du solénoïde pouvant endommager celui-ci. Un temps de récupération évite l'activation à la chaîne du solénoïde, le protégeant contre la surchauffe.

entrée CV

L'entrée CV écoute un signal audio et actionne le solénoïde si la moyenne de ce signal dépasse un seuil réglable par un potentiomètre. Le module peakDetector.py écoute l'entrée micro connectée à une petite carte son USB via pyaudio Un callback est appellé tous les 512 échantillons pour en additionner les valeurs. Si la somme des valeurs est supérieure au seuil, le solénoïde est déclenché et une led RGB s'éclaire en rouge. Si elle dépasse un seuil de signal, la led s'allume en vert pour manifester la présence de son sur l'entrée. Le volume de l'entrée (et l'activation du préampli micro) est réglée par un second potentiomètre marqué gain. Ce volume est directement réglé dans ALSA par amixer. La lecture des potentiomètres se fait au travers d'un MCP3008 connecté au bus SPI natif du raspberry pi et lu via spidev

routing audio

Contrairement à certaines cartes son bien plus onéreuses, la Behringer U-PHORIA UMC202 ne permet pas un monitoring hardware. Le routing audio doit donc se faire par voie logicielle, en passant régulièrement un tampon de l'entrée vers la sortie. Pour garder une latence inférieure à 5ms, ce tampon ne doit pas être trop grand et sa fréquence d'envoi vers la carte doit restée élevée. Ces exigences n'étant pas nécessairement compatibles avec le scheduler natif de raspbian, un noyau compilé en temps réel et tous les services non-utilisés sont désactivés (bluetooth, triggerhappy, dbus…) Le raspbian choisi est une version headless sans interface graphique pour économiser des ressources. Le code implémentant le routing audio se trouve dans le module audio.py du dossier client. La communication avec la carte son se fait via un serveur jackd (v1, la v2 s'appuyant sur dbus qui nécessite un serveur X). Le serveur et client Jack communiquent avec le script python par le module jackclient La lecture des samples s'appuie elle sur jack-play, l'ajustement des volumes se faisant directement sur ALSA via amixer.

serveur OSC

Un serveur OSC écoute en UDP sur le port 9000 pour recevoir les ordres transmis par le serveur comme les messages directement envoyés depuis puredata/maxMSP (cf liste des commandes OSC). Le client envoie également un message /heartbeat toutes les secondes pour permettre au serveur de détecter la déconnexion des clients. Il peut également lui transmettre la liste de ses fichiers audio, son nom d'hôte ainsi que son adresse IP pour permettre à celui-ci de maintenir une liste de clients connectés à jour.

Côté serveur

Le serveur contient son propre code, stocké dans le repertoire server à la racine du git. Le raspbian utilisé est une version complète, avec interface graphique pour pouvoir accéder à son interface web directement à l'aide d'un écran et d'un clavier.

gestion des clients

Le module clients.py gère la tenue d'une liste de clients en ligne comprenant les notes midi de chacun, leur volume, la liste de leurs fichiers wav et la dernière date à laquelle ils ont été vus. Il s'occupe également de marquer les clients comme déconnectés en l'absence de heartbeat et d'ajouter de nouveaux clients au fur et à mesure qu'ils se connectent à lui. La liste des clients connus est écrite dans un fichier json pour garder ces informations en mémoire après un redémarrage du serveur. Ce module permet en outre de découvrir tous les clients présents et de stocker leur adresse IP, envoyant ces informations vers l'interface web où elles peuvent être consultées et modifiée par l'utilisateur.

serveur OSC

Le serveur écoute l'OSC par UDP sur le port 8000, il peut ainsi recevoir des commandes des clients comme de l'utilisateur, voir liste des commandes OSC ci-dessous

interface web

L'interface web se résume à une page servie par flask et mis à jour dynamiquement par flask-socketio. Du javascript utilisant JQuery permet la modification dynamique de la DOM côté utilisateur. Côté fichiers, flask-uploads gère l'envoi de fichiers par requêtes POST/multipart

Liste des commandes OSC

Pour pouvoir communiquer en OSC avec les modules, il est impératif :

  1. d'allumer le serveur (et de lui laisser environ deux minutes pour démarrer)
  2. de se connecter au réseau wifi qu'il crée :

    SSID : masterPi

    PSK : bbqCvsN8

commandes du serveur

Le serveur est joignable à l'IP 10.0.0.1 au sein du réseau wifi ou par son nom d'hôte masterpi.local. Il écoute sur le port 8000.

commandes des clients (modules)

Les clients peut-être directement contacté par son nom d'hôte au sein du réseau wifi. Ce nom peut être édité sur l'interface web. Par exemple, pour un client nommé bidule, les messages OSC peuvent être envoyés à bidule.local au lieu de 192.168.0.24 Chaque client écoute en UDP sur le port 9000.

Dev interface

html en cours d'intégration(bootstrap4) maj-index-static

Photos