Ateliers
Pure data & capteurs - actionneurs

Formations de Juin 2008 - Main d'Oeuvres, CRAS, Saint-Ouen - Zandrine Chiri/Interface-Z

Première journée :
Initiation aux logiciels de gestion temps réel, en particulier PD, acquisition des données, bases de Pure-Data pour la gestion des capteurs et actionneurs, notions de protocole Midi.
Cette journée prépare à la formation du week end suivant.
01/07/2008 - Salle Star Trek (Deuxième étage) à Mains d'Œuvres
Deuxième journée :
Atelier capteurs, panorama des capteurs, exemples.
07/06/2008 - Atelier 12 (Premier étage) à Mains d'Œuvres
Troisième journée :
Atelier actionneurs.
08/06/2008 - Atelier 12 (Premier étage) à Mains d'Œuvres

IV - Exemples pratiques

1 - Lecture d'un son à vitesse variable

Action sur un son.

a - Activer le son

Pour être sûr que le son se joue dès l'ouverture du patch, un loadbang envoie un message pd dsp 1. C'est équivalent à "Audio On" ou à cocher Compute Audio.

b - Préparation du son

Nous avons vu dans des démos de capteurs qu'un son pouvait se jouer directement avec un objet readsf~. Ce n'est pas le cas ici. Le son est placé dans une table et cette table sera ensuite lue.

La table se crée avec un array. Dans les properties, il faut lui donner une taille plus grande que 100 (par défaut) pour entendre du son. Une taille de 44103 permet de jouer une seconde de son. Il faut aussi lui assigner un nom spécifique et reconnaissable facilement.

L'objet soundfiler permet ensuite de placer le son dans la table, grâce à un message read + nom du fichier son + nom de la table.

On peut lire des fichiers non compressés, aif et wav. Attention à l'orthographe, aux majuscules et à l'extension. Ne pas mettre d'espace dans le nom de fichier.

c - Lecture du son à vitesse variable

Cette étape se teste dans un premier temps sans capteur, avec des nombres sur les paramètres variables.

L'objet central est tabread4~. Il prend en argument le nom de la table contenant le son. Il reçoit en entrée un index correspondant à ce qu'il va lire dans la table.

En amont de tabread4~ se trouvent les objets permettant de naviguer dans la table.
- L'objet phasor~ est un générateur d'onde en dent de scie. Il prend en entrée la fréquence, le nombre de fois où le morceau de son est joué en 1 seconde. Il permet aussi de créer une boucle. Le son reste reconnaissable tant que le nombre est en dessous de 4. Au-dessus, on obtient une vibration dont le timbre change avec la fréquence.
- Un objet *~ permet de choisir la longueur de l'extrait joué, toujours à partir du début. Le * 441 au dessus permetde jouer sur des fractions de centièmes de seconde. Une valeur 10 fait joué le premier dixième du son, une valeur 100 fait jouer la totalité du morceau.
- Le +~1 évite de jouer le premier échantillon dans la table, ce qui est mieux pour le fonctionnement de tabread~. De même les trois derniers sont évités car la table a une taille de 44103 et non 44100 pile.

En aval de tabread4~ se trouvent les objets influant sur la diffusion du son.
- L'objet dac~ représente les haut-parleurs, avec deux entrées par défaut pour la stereo.
- Le *~ affecte le volume. Il a une entrée chaude qui reçoit le son et une entrée froide où l'on envoie un chiffre correspondant au volume.
- L'objet line~ envoie une rampe qui rejoint un objectif en un temps donné. Sa fonction est d'envoyer des variations de volumes douces pour éviter les craquements. L'objet pack permet de créer un message à deux paramètres pour line~ : le premier correspondant à la valeur à atteindre et le deuxième au temps en ms. Les messages 0 et 1 se traduisent en "muet" et "volume normal".

d - Capteurs

L'invocation correspondant à la carte est posée dans le patch (douze_ana_mode7bits ou 2_ana). Les valeurs de deux capteurs sont envoyées sur des send (s). Le couple send / receive remplace un fil, ce qui rend le patch plus clair. Il faut choisir les sorties en fonction de la position des capteurs branchés sur la carte.

Les objets receive (r) sont connectés sur la fréquence du phasor~ et sur la taille de l'extrait joué.

Les capteurs utilisés pour cet exercice sont des capteurs analogiques, comme les capteurs d'intensité lumineuse, de pression et de distances, ou les potentiomètres souples.

Les données brutes permettent d'explorer les effets combinés de deux larges variations de valeurs. Les données peuvent aussi être divisées pour jouer sur des variations plus fines en gardant un aspect reconnaissable du son. De plus, une soustraction donne la possibilité de jouer le son en sens inverse.

2 - Un peu de Gem

Exemple de programmation Gem.

a - Fenêtre Gem

L'objet gemwin crée une fenêtre Gem où s'affichent les objets 3D et images. Il prend des messages en paramètres pour gérer l'aspect de la fenêtre. Le message create, 1 ouvre la fenêtre graphique et lance le rafraîchissement d'affichage.

b - Objets 3D

Tout objet 3D fait partie d'une chaîne Gem, commençant par gemhead et finissant par l'objet 3D. Entre les deux s'intercalent les objets de couleur, texture, position, déformation, etc.

Une lumière est également un élément 3D, à mettre sous un gemhead. Ici la world_light éclaire la scène.

Plusieurs objets 3D (ici des sphères) peuvent s'enchaîner dans une seule chaîne Gem.

L'objet translateXYZ affecte la position spatiale des sphères dans l'espace 3D de la fenêtre graphique.

L'objet colorRGB affecte la couleur des sphères (par les entrées rouge, vert, bleu) et leur transparence (dernière entrée). Ces informations sont des nombres compris entre 0 et 1.

c - Changement de couleur par capteur

Les données d'un capteur branché sur la première entrée d'une interface 2 Analogiques arrivent par le ctlin 0. Ces données sont envoyées à la fois sur la position en X des sphères et sur les composantes rouge, verte et transparence de la couleur.

Les données sont traitées différemment selon leur destination :
- pour la position, la soustraction et la division permettent de centrer l'objet dans la fenêtre lorsque le capteur est à mi-course.
- pour la couleur, une division par 127 donne une valeur comprise entre 0 et 1.

3 - Lecture d'un son

Lecture de son.

Ce petit patch constitue un module basique de lecture de son, fréquemment utilisé. Il sera réutilisé dans un autre exemple. Les objets *~ et dac~ ont été présentés plus haut.

L'objet central est readsf~. Pour jouer un fichier son, il faut envoyer un message open + nom du fichier son sur le readsf~ suivi d'un message "1" pour lancer la lecture. Un message "0" arrête le son.

L'objet trigger (t b b b) permet de cascader ces événements dans le bon ordre, d'abord open, puis 1, puis un arrêt du son par 0 au bout de 800 ms. Le bang au-dessus sert à lancer manuellement la lecture du son.

Dans cet exemple un capteur est utilisé pour jouer sur le volume de diffusion. Les données du capteur (branhé sur un 2 Ana) sont divisées par 64 pour être ramenées dans une gamme de volume utilisable.

4 - Déclenchement d'événements par capteur pyroélectrique

Déclenchement par capteur pyroélectrique.

a - Lecture de fichier son

La structure de lecture de son vue précédemment est réutilisée ici pour jouer un fichier son lorsqu'un spectateur bouge.

Il faut créer un patch qui envoie automatiquement un bang sur les messages open puis 1 pour lancer le son quand quelqu'un bouge.

b - Filtrage du capteur pyroélectrique

Les valeurs du capteur pyro analogique sont centrées vers 62 en absence de mouvement. Elles oscillent au dessus et en dessous de cette valeur lorsqu'un mouvement est détecté. Il faut donc poser deux seuils de part et d'autre de la valeur de repos, en vérifiant cette valeur au départ. Nous considérons ensuite que les valeurs comprises entre ces seuils, autour de la valeur de repos ne sont pas assez significatives pour déclencher un son et que celles qui dépassent (au-dessus ou en-dessous) révèlent un mouvement donc déclenchent le son.

Ce double seuil se fait grâce aux objets moses. Deux moses successifs délimitent trois zones :
- les valeurs inférieures à la valeur de repos, sur la sortie de gauche du premier moses ;
- les valeurs de repos, qui ne déclenchent rien, sur le sortie de gauche du deuxième moses, entre 55 et 65 ;
- les valeurs supérieures à la veleur de repos, sur la sortie de droite du deuxième moses.

Les valeurs inférieures et supérieures sont prises en compte en même temps pour lancer la lecture du son.

c - Une lecture à la fois

Tel quel, ce patch joue le son de façon désordonnée et bégayante. En effet, le son est lancé à chaque donnée individuelle, car un mouvement correspond à tout un flot de valeurs envoyées par le capteur. Pour éviter cet inconvénient, l'objet onebang est intercalé entre les seuils et le lancement du son.

onebang laisse passer un seul bang puis se ferme. Il doit être réactivé par un bang sur sa deuxième entrée pour pouvoir à nouveau laisser passer un unique signal.

La première donnée dépassant l'un des seuil envoie un bang à travers le onebang, qui en activant le trigger lance le son. Les données suivantes ne sont pas prises en compte. Le son se joue donc proprement sans interruption pendant deux secondes (délai arbitrairement choisi...).

Au bout des deux secondes, un bang réactive le onebang. Il est alors possible de recommencer.