Par Jessie JAMES, Inès SOGADZI et Lucie LOPEZ

NOTE D’INTENTION DU PROJET DE DISPOSITIFS INTERACTIF :

EVMAN - L3 - TD2

Par Jessie JAMES, Inès SOGADZI et Lucie LOPEZ

1- Le point de départ :

Le point de départ de ce projet était notre volonté de faire de l’art génératif. Ceci induisait que nous allions devoir utiliser un logiciel qui nous permettait d’avoir un retour visuel puisque l'art génératif “est une pratique utilisant des algorithmes pour générer de manière autonome une œuvre. Tout d'abord, [il s’agit de créer] des règles qui fixent des limites au processus de création. Ensuite, un ordinateur suit ces règles pour produire [une] œuvres.” (https://www.unitec.fr/lart-generatif-algorithmes-au-service-de-la-creation/#:~:text=L'art%20g%C3%A9n%C3%A9ratif%20est%20une,pour%20produire%20de%20nouvelles%20%C5%93uvres.)

Ainsi, Perlin est un dispositif interactif qui dépeint les activités corporelles sous la forme de sortes de racine, un motif créé grâce aux propriétés des “bruits de perlin”, d’où le nom donné à l’installation. 

Du nom de son inventeur Ken Perlin, le bruit de perlin est une texture procédurale créée par un algorithme. Il peut être utilisé pour réaliser des nuages, des paysages ou encore des textures à motifs comme le marbre grâce à son aspect relativement réaliste. 

Cela résulterait de l’utilisation d’une séquence de nombres pseudo-aléatoires qui serait plus fluide, ce qui la rendrait également plus contrôlable.

Processing est un logiciel qui inclut déjà l'algorithme de bruit de Perlin dans la fonction noise(). Ainsi, pour notre retour visuel mais également pour cette fonction, nous avons décidé d’utiliser Processing.

2- Le principe 

Notre but est d’établir le “profil” de chaque personne à partir de ses constantes, en traduisant des phénomènes physiques et en rendant visible certaines fluctuations. Ainsi, nous allons capter certaines données dont la température, le rythme cardiaque et la respiration à l’aide d'un capteur de température,  d'un capteur qui enregistre les pulsations et d'un capteur de respiration.  Tous les capteurs sont reliés à Max et les données reçues sont transférées à Processing afin que les conditions déterminées dans le code produisent le motif correspondant au profil de la personne. En fonction des données, nous observerons des variations sur la couleur, l’épaisseur et la courbure des branches, rendant ainsi chaque expérience et dessin unique. Au départ, il était convenu que nous allions modifier l’acuité des branches plutôt que leur courbure, cependant le principe même du bruit de perlin rendait cela impossible puisque justement, les lignes sont censées être douces et fluides.

Donc, afin d’apporter une image toute autre que celle des graphiques que l’on voit habituellement lors de la prise de certaines constantes, il s’agissait de faire en sorte que, grâce aux données reçues, l’utilisateur évolue dans un environnement étrange et nouveau, comme pour le sortir de sa zone de confort. Un peu dans l’idée des projets de la TeamLAB au Japon, nous souhaitions que le public soit transporté dans un univers virtuel en perpétuel évolution. Ainsi, les racines se forment et changent de couleurs, de courbure et d’épaisseur.

Nous nous sommes répartis le travail de tel sorte que Jessie s’occupait du code sur Max. Inès s’occupait du code sur Processing. Enfin, Lucie s’occupait du dossier pour le rendu final.

Pour réaliser ce projet, nous avons utiliser plusieurs capteurs : 

• Nous avons tout d’abord un capteur de température de type contact, c’est-à-dire que la température sera prise au contact de la peau de l’utilisateur/rice. Celle/celui-ci tiendra l’objet entre deux de ses doigts (ou alors iel pourra souffler dessus) et les données seront récoltées par Max puis envoyé à Processing. Ce capteur déterminera de quelle couleur seront les racines, grâce à des intervalles que nous avons déterminées sur Processing. Chaque intervalle constitue une condition qui donne l'autorisation ou non à l’ordinateur de modifier de manière autonome le programme de base. “La base de la condition, c'est la comparaison. Avant de pouvoir agir selon une condition, il faut d'abord formuler la question que Processing doit se poser. Cette question sera quasiment toujours une question de comparaison. Si le résultat de la question est « oui », Processing exécutera une suite d'instructions. Si la réponse est non, il exécutera une autre”. ( https://fr.flossmanuals.net/processing/les-conditions/ )

Ici, si certains seuils sont dépassés, l’ordinateur exécutera les instructions que l’on aura prédéterminé. Ainsi, si la température est inférieure à 37 °C (ce qui signifie que l’utilisateur/rice est fiévreux), les racines seront bleues. Si elle est comprise entre 37 et 39 °C (température normale), les racines seront oranges. Enfin, si elle est supérieure à 39 °C (l'utilisateur/ice est également fiévreux) elles seront rouges.

Le défi était de convertir les données en MIDI du capteur, en une température en degré Celsius. Jessie a calculé le coefficient de proportionnalité qui nous permettait de convertir les données directement sur Max. Ensuite, les données étaient envoyées tel quel vers processing où les conditions déterminent déjà les intervalles voulues.

• Le second capteur est également un capteur de contact. En effet, il s'agit d’un petit capteur placé dans un gant, à l'abri de la lumière, sur lequel nous devons placer un doigt, et qui réagit aux pulsations envoyées par le cœur dans les veines. Nous utilisons donc ce capteur afin de saisir le rythme cardiaque qui agit sur la courbure des racines. S’il est inférieur à 60 battements/min (bradycardie), les branches, même s’il leur restera quelques ondulations, seront relativement raides. S’il est compris entre 60 et 100 battements/ min (rythme normal), elles auront davantage d’arrondis. Enfin, s’il est supérieur à 100 battements/min (tachycardie) les branches seront beaucoup plus courbées.

Ce capteur a été quelque peu capricieux car il n’était pas suffisamment sensible. Mais un coup de tournevis et le tour était joué ! Cependant, la sensibilité du capteur a également été une source de problème. Nous avions beaucoup de mal à gérer la pression avec laquelle il fallait appuyer sur le capteur afin qu’il puisse détecter la pulsation, et ce à cause du fait qu’il soit extrêmement sensible justement. La pulsation n'est pas détectée si nous appuyons trop fort ou pas assez. Alors, la majorité du temps nous n’avons pas utilisé ce capteur mais nous l’avons remplacé par un mtr (des captations préenregistrées du capteur). D’ailleurs, nous utilisions également des mtr lorsque nous n’avions pas accès aux capteurs.

Pour l’envoi vers Processing, nous ne voulions pas utiliser les variations de données qui oscillent entre un minimum et un maximum, nous voulions utiliser le nombre de battement effectué en une minute. Alors, nous avons utilisé un compteur qui comptabilise le nombre de pics en une minute. 

C’est l’objet r end qui permet de réinitialiser le compteur au bout d’une minute. Définit dans un sous-patch,  il consiste tout simplement à envoyer le signal envoyé par le “metro 6000” vers les objets auxquels il est lié dans le patch principal, ce qui va non seulement redémarrer le compteur. Dans ce même sous-patch on peut redémarrer manuellement le métro pour permettre aux utilisateurs de déclencher les 1 minutes que lorsqu’ils sont prêts.

Au préalable, nous avons dû débruiter les données afin de justement prendre en compte uniquement les réels pics et non les bruits du capteur. Ici, un seuil est établi et seules les données supérieures à 30 sont prises en compte.

•  Enfin, nous avons utilisé une ceinture abdominale qui capte la respiration. Placée au niveau du ventre, elle détecte l’inspiration et l’expiration grâce aux mouvements effectués par le ventre. Les données reçues déterminent l’épaisseur des racines. Si  le nombre de respirations/min est inférieur à 13 (trop faible), l’épaisseur des branches sera moindre. Si le nombre de respirations/min est compris entre 13 et 20 (rythme normal) l’épaisseur sera déjà plus conséquente. S’il est supérieur à 20 (trop élevé) les branches seront relativement épaisses.  Ici nous n’avons pas rencontré de problème particulier, à part le fait que nous avons dû augmenter la sensibilité du capteur.

Pour envoyer les données vers Processing, la respiration est captée et analysée à l’aide d’un comparateur à hystérésis qui établit un seuil dynamique alternant entre une valeur haute et une valeur basse. En effet, nous ne voulions pas envoyé les données tel quel vers processing. Il ne s’agissait pas de savoir entre quelles valeurs minimum et maximum la respiration variait, mais il s’agissait de savoir quel nombre de respiration était effectué en une minute. Alors, le principe du comparateur à hystérésis, relié à un compteur, nous permettait de compter le nombre de respiration grâce aux seuils prédéterminés qui considérait un franchissement comme une respiration. Ici les seuils sont <50 et >70. Ce comparateur à double seuil permettait de stabiliser la détection et de la rendre plus certaine.

Afin d’établir un lien entre Max et Processing, la seule solution était d’utiliser le protocole OSC (Open Sound Control). C’est donc cet objet relié aux compteurs et au slider dans Max qui permettait d’envoyer les données vers Processing.

Sur Processing, ce sont ces lignes de code qui établissent la correspondance. On y observe justement la déclaration du protocole OSC, ainsi que les conditions qui permettent de relier les capteurs.

Concernant les conditions qui déterminent l'aspect des racines, voici un exemple (en sachant qu’il y en avait 27 en tout, puisque nous avions pris en compte toutes les combinaisons possibles) :

“fill(0, 0, 255);” est la ligne de code qui détermine la couleur.

Ensuite, “circle (position.x, position.y, 0.5);” est celle qui détermine les positions des points et leur épaisseur. “position” est une variable qui a été déclarée plus tôt dans le code et qui ne détermine pas réellement la position des points qui restent “aléatoires”. C’est la donnée chiffrée, ici 0.5 qui nous permet de faire varier l’épaisseur.

Enfin, “velocity = PVector.fromAngle(noiseValue* PI);” et plus particulièrement “noiseValue* PI” nous permet de déterminer dans quelle direction vont les branches et par conséquent quelle sera leur courbure.

Les données sont envoyées en tant réel, ce qui nous permet de voir l'évolution des constantes du corps, qui feront à leur tour varier le schéma des racines et ce, jusqu'à ce que les données se réinitialisent au bout d'une minute.

Nous avions également  l’ambition d'utiliser un capteur de distance (proximètre) afin de contrôler l’apparition des branches (plus l’on s’approche plus des branches apparaissent). Le capteur devait prendre en compte la distance à laquelle se trouvait le spectateur/rice et en fonction de sa valeur plus ou moins grande les racines seraient plus ou moins visibles. Ce capteur aurait dû fonctionner grâce à des ondes infrarouges à proximité, c’est pourquoi nous voulions poser un tapis d'environ 2m² au sol afin de délimiter la zone pour le public. Finalement, nous avons abandonné cette option car notre installation nous convenait telle quelle, d’autant plus que le dispositif aurait été très complexe à gérer techniquement mais également sur Processing. 

Voici notre schéma fonctionnel : 

Voici les patchs et vidéos :

Télécharger « perlin.pde »

Télécharger « perlin.maxpat »

Télécharger « perlin.maxpat »

Télécharger « perlin.pde »