Différences

Ci-dessous, les différences entre deux révisions de la page.

--- projets:gmem-cirva:accueil [2019/11/20 17:13]
laurent [Modules : côté client]
+++ projets:gmem-cirva:accueil [2020/02/28 16:52] (Version actuelle)
laurent [Liste des commandes OSC]
@@ Ligne 6: / Ligne 6: @@
   * [[https://github.com/reso-nance/gmem-sirva|git du projet]]
   * [[http://gmem.org/evenement/paysage-de-propagation-cirva/|Descriptif du projet sur le site du GMEM]]
+  * [[http://www.reso-nance.org/GMEM|télécharger les images]] des raspberry pi
@@ Ligne 58: / Ligne 59: @@
 === 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, permettant d'éviter sa surchauffe.
+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é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//
+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 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 [[https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions|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//.
+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 [[https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions|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===
@@ Ligne 74: / Ligne 75: @@
 ===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 :
+  - d'allumer le serveur (et de lui laisser environ deux minutes pour démarrer)
+  - de se connecter au réseau wifi qu'il crée :<WRAP center round info 20%>
+SSID : **masterPi**
+PSK : **bbqCvsN8**
+</WRAP>
+===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**.
+  * **/whoIsThere** : demande au serveur une liste de clients connectés. Le serveur répondra à l'expéditeur par un message OSC sur le port 9000 contenant en argument le nom de chaque client actuellement connectés
+  * **/knownClients** : renverra à l'expéditeur sur le port 9000 le message OSC "/knownClients" contenant la liste de tous les appareils connus, connectés ou non
+  * **/shutdown** : provoque l'extinction du serveur et de tous ses clients connectés à ce moment
+  * **/readMidi** : lit instantanément un fichier midi préalablement stocké sur l'ensemble des machines
+    * //str// nomDuFichier : nom du fichier midi stocké sur le serveur (sensible à la casse)
+  * **/stopMidi** : stoppe instantanément la lecture du fichier midi en cours
+  * **/delete** : supprime un fichier midi du serveur
+      * //str// nomDuFichier : nom du fichier midi stocké sur le serveur (sensible à la casse)
+      * //(facultatif) str// nomDuFichier : plusieurs noms de fichiers peuvent être donnés en même temps
+      * ex : ///delete fichier1.mid fichier2.mid fichier3.mid//
+===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**.
+  * **/solenoid ** :  pulse le solénoide une fois
+      * //(facultatif) int// durée : durée d'activation du solénoïde en ms. Limitée en interne pour éviter la surchauffe du solénoïde
+      * ex : ///solenoid 50//
+  * **/play** : lit un fichier audio stocké dans le client
+      * //str// nomDuFichier : nom du fichier sans le chemin complet, ex: //groovyTune.wav// (peut contenir des espaces, caractères accentués...)
+      * //(facultatif) str// sortie audio : sortie utilisée pour lire le fichier son, par défaut celle du transducteur. Peut être soit //transducer// soit //analogOUT//, sensible à la casse
+      * //(facultatif) str// sortie audio2 : seconde sortie utilisée pour lire le fichier son simultanément. Peut être soit //transducer// soit //analogOUT//, sensible à la casse
+      * ex : ///play groovyTune.wav analogOUT//
+  * **/stop** : stoppe instantanément la lecture du fichier wav en cours
+  * **/delete** : supprime un fichier audio du serveur
+      * //str// nomDuFichier : nom du fichier audio stocké sur le serveur (sensible à la casse)
+      * //(facultatif) str// nomDuFichier : plusieurs noms de fichiers peuvent être donnés en même temps
+      * ex : ///delete fichier1.wav fichier2.wav fichier3.wav//
+  * **/route** : connecte une entrée audio à une sortie audio
+      * //str// nomDeLentrée : peut être soit //microphone// soit //analogIN//, sensible à la casse
+      * //str// nomDeLaSortie : peut être soit //transducer// soit //analogOUT//, sensible à la casse
+      * ex : ///route microphone transducer//
+  * **/disconnect** : déconnecte le routing effectué entre une entrée audio et une sortie audio
+      *  //str// nomDeLentrée : peut être soit //microphone// soit //analogIN//, sensible à la casse
+      * //str// nomDeLaSortie : peut être soit //transducer// soit //analogOUT//, sensible à la casse
+      * ex : ///disconnect microphone transducer//
+  * **/mute** : coupe le son de l'entrée ou la sortie sélectionnée
+      * //str// nom : peut être //microphone//, //analogIN//, //transducer//, //analogOUT//, sensible à la casse
+      * //(facultatif) str// nom : idem, permet de muter plusieurs canaux en même temps
+      *  ex : ///mute analogOUT transducer//
+  * **/unmute** : rétablit le son de l'entrée ou la sortie sélectionnée
+      * //str// nom : peut être "microphone", //analogIN//, //transducer//, //analogOUT//, sensible à la casse
+      * //(facultatif) str// nom : idem, permet de dé-muter plusieurs canaux en même temps
+      * ex : ///unmute analogOUT//
+  * **/toggle** : inverse l'état du mute de l'entrée ou la sortie sélectionnée
+      * //str// nom : peut être //microphone//, //analogIN//, //transducer//, //analogOUT//, sensible à la casse
+      * //(facultatif) str// nom : idem, permet de basculer le mute de plusieurs canaux en même temps
+      * ex : ///toggle analogOUT//
+  * **/volume** : règle le volume de l'entrée ou la sortie sélectionnée
+      * //str// nomDeLEntreeSortie : peut être //microphone//, //analogIN//, //transducer//, //analogOUT//, sensible à la casse
+      * //int// volume 0~100 : inaudible à 0%, plein volume à 100%, courbe logarithmique.
+      * ex : ///volume analogOUT 87//
+  * **/shutdown** : provoque l'extinction de cette machine
 ===== Dev interface =====
 {{:projets:gmem-cirva:paysage-de-propagation_ui_001.jpg?600|}}

Wiki

Outils pour utilisateurs

Outils du site

Différences

Outils de la page