• Porteur du projet : GMEM / Reso-nance
• Date : 09/2019
• Licence : libre !
• Contexte : phase 1
• Fichiers : lien
• Lien : lien vers un site éventuellement

• Minimum de contact entre le support et l'objet en verre
• Câbles apparent
• Possibilité de déplacer transducteur, micro et solénoide à la main afin de continuer
• l'expérimentation sonore
• Possibilité de remplacer transducteur, micro et solénoide à la main (?)
• Entrées et sorties analogiques audio (pour brancher d'autres pièces en mode modulaire)
• I/O alignées sur un niveau ligne (ce qui implique amplification à l'intérieur du prototype)
• Entrée numérique pour le contrôle de la machine ou l'upload de partitions pour le
• mode autonome
• Entrée alimentation

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.

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.

• Lecture et stockage de fichier sons
• Lecture et stockage de fichiers MIDI pour le solénoïde
• Plusieurs contrôles avec accès OSC
• Mute on/off micro
• Mute on/off sample
• Mute on/off transducteur
• Mute on/off sortie analo
• Envoi micro vers transducteur
• Envoi micro vers sortie analo
• Envoi sample vers transducteur
• Envoi sample vers sortie analo
• Envoi entrée analo vers transducteur
• Envoi entrée analo vers sortie analo
• Master sortie transducteur
• Master sortie analo

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

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, permettant d'éviter sa surchauffe.

L'entrée CV écoute un signal audio et actionne le solénoide 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énoide 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

Contrairement aux cartes son plus haut de gammes, 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. 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 pyJack La lecture des samples s'appuie elle sur jack-play, l'ajustement des volumes se faisant directement sur ALSA via amixer.

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