Pure data & Interactivité

Cours 08 - 09

• 19-24/03/2012 - 02/04/2012 : Cours 08 / 09 / 10
  - TD installations diverses

I - Descriptions des Projets

Ils pourront être menés en binômes mais les notes seront individuelles. Les notes se feront sur rapport de projet, du même type que celui demandé pour le projet commun.

Les projets devront utiliser Pure Data au moins en partie. Ceratins pourront faire intervenir Processing. Si des étudiants travaillant sur leur propre portable souhaitent manipuler de la video, nous pourrons faire un tour rapide d'Isadora sur ces machines, outil bien plus rapide à prendre en main que PD. Les patchs de communication entre PD et Processing, ou entre PD et Isadora seront mis à disposition.

• Pong
  • 2 capteurs
  • Affichage graphique en PG (Gem), Processing ou Isadora
  • Gestion des rebonds
  • Redémarrage automatique lorsque la balle est perdue
  • Eventuellement affichage des scores
  • Eventuellement lancement de sons lors de l'impact de la balle sur les raquettes ou les murs
• Theremin
  • 1 capteur pour le pitch, éventuellement un autre capteur pour le volume ou pour un deuxième son harmonisé au premier
  • Utilisation d'un sample mis dans un buffer
  • Polyphonie, soundfiler
• Suivi lumineux
  • Un capteur longue portée ou plusieurs capteurs courte portée
  • Suivi d'un spectateur se déplaçant le long d'un mur ou d'un couloir
  • Au moins 4 lumières s'allument pour le suivre, avec des crossfades
  • Changement de son pour chaque étape lumineuse
• Fenêtres
  • Graphisme en PD ou Processing
  • Le spectateur s'approche d'un écran où est dessiné une fenêtre fermée. La fenêtre s'ouvre, les rideaux sont fermés.
  • Les rideaux s'ouvrent lorsqu'il est très près de l'écran. S'il hésite à cet endroit tout reste ouvert. S'il recule, les rideaux puis les fenêtres se referment lorsqu'il est loin de l'écran.
  • Lancer un son à chaque étape.
• Musique en chaîne
  • Dispositif permettant d'explorer des morceaux de musique les uns après les autres
  • Un capteur sert à gérer le volume du son joué, un autre ou le même sert à passer d'un morceau au suivant
  • Le volume se matérialise sur une intensité lumineuse
  • Les sons choisis sont courts ou longs et se jouent en boucle jusqu'à ce que le joueur choisisse de changer de son
  • Eventuellement : affichage du nom ou numéro du son en cours de jeu
  • Ne pas utiliser gamelle.wav ou nixon.aiff...
• Scanner lent
  • Un capteur sur un servomoteur ; Le servomoteur effectue un demi-tour.
  • Dessiner le profil des objets mesurés par le capteur
  • Graphisme préférentiellement en Processing
  • Eventuellement en 3D, avec 2 servomoteurs
• Défilement d'images
  • Analyse de gestuelle/sens de passage avec 2 capteurs
  • Avancée dans une banque d'images dans un sens ou dans l'autre selon le geste détecté
  • Graphisme en Pd, Processing ou Isadora
  • Lancer un son au passage de la main
  • Eventuellement : La hauteur de la main, ou la vitesse de passage influence la durée du crossfade
• Foule
  • Chaque fois qu'un spectateur entre dans une pièce, une nouvelle miniature apparaît sur un écran (un nouveau visage si possible)
  • S'il s'en va, une image disparaît
  • 2 capteurs pour détecter le sens de passage et faire un compteur
  • un son à chaque entrée, un autre à chaque sortie

II - Contenu des rapports de projets

Quelque soit le projet, le rapport suit le même principe que pour le projet de l'installation sur la chaise : il faut analyser ce que l'on fait, expliquer ses interprêtations et détailler les choix effectués du point de vue du matériel et de la programmation.

Les projets suivent une démarche de recherche et d'expérimentation : les patchs ne seront pas forcément terminés dans les temps des trois séances, il se peut que des solutions envisagées s'avèrent fausses, il se peut que des contraintes inattendues apparaissent, toutes choses courantes en projets appliqués. Cela n'est pas forcément pénalisant, tant que le rapport fait état des recherches, des éventuelles fausses pistes et des problèmes détectés, ainsi que des pistes à creuser pour corriger ces problèmes.

Le rapport doit contenir trois niveaux d'analyse et de description :

1 - Description et comportement de l'installation

Décrire l'installation choisie et les interprêtations personnelles qui en découlent (les choix personnels par rapport à l'énoncé, les ambiances ou le contexte si c'est un projet personnel). Par exemple les choix d'ambiance sonore ou visuelle, ou les couleurs de lumière, ou la réaction espérée du spectateur (ou du performer), se décrivent dans cette section. Expliquer la mise en scène si le sujet s'y prète, ou la localisation des éléments.

Déterminer le comportement de l'installation par rapport au spectateur/performer, séparer des étapes ou des états de fonctionnement différents au cours du temps : que ce passe-t-il dans tel ou tel cas, quelles sont les possibilités d'action du spectateur ? Comment se manifeste cette action auditivement ou visuellement ?

Quels sont les matériels nécessaires au projet ? Combien de capteurs, situés où ? Combien de lampes, s'il y en a ? Utilisation d'images ? Graphismes ? Utilisation de sons ? Génération de sons ?

Il n'est pas utile à cette étape de décrire formellement chaque action en fonction des capteurs, ces précisions seront détaillées dans la section suivante. Cette section aide à cadrer le projet et à établir les choix personnels.

Des schémas sont bienvenus mais pas obligatoires, s'ils aident à expliquer des choses.

2 - Analyse matérielle et logicielle générale

Décrire les étapes successives ou les différents états de l'installation, cette fois-ci du point de vue de la programmation :

- qu'est-ce qui est automatique ?
- présence / absence de spectateur devant le capteur,
- près du capteur / loin du capteur ?
- comportement des lumières, intensité, dépendance ou non du capteur ou du son ?
- combien de sons, quel son à quelle étape, à quel volume, en boucle ou pas ?
- y a-t-il un autre logiciel en réseau OSC, à quoi réagit-il, que reçoit-il comme instruction à chaque étape ?
- qu'est-ce qui détermine le passage d'une étape à une autre ?
- ce passage se fait-il d'un coup ou progressivement ?
- l'activation d'une étape implique-t-elle de désactiver quelque chose dans une autre étape ?

Il est souvent préférable de préprogrammer les pilotages d'actionneurs (sons, lumières, graphismes) avant des les connecter au reste du programme (captation et analyse). Une première étape du patch peut être de lancer ces actions à la souris, pour vérifier qu'elles fonctionnent et que l'enchaînement de l'une à l'autre se fait correctement.

3 - Détails de la programmation

Décrivez les objets utilisés (ou les fonctions dans le cas de Processing) pour chaque étape. Les modules préprogrammés du patch du cours 5 peuvent être utilisés dans plusieurs des projets proposés.

Si du temps est passé sur une solution qui s'avère ne pas fonctionner, décrivez pourquoi cela ne marche pas.

Lors de la rédaction, les sections 2 et 3 peuvent être regroupées ensemble, pour éviter les redites, mais il ne faut pas oublier d'expliciter les objets utilisés (section 3), sans rester seulement à la description générale du programme (section 2).

Les rapports peuvent être écrits à la main ou informatisés. Les patchs peuvent être organisés en patchs successifs au cours du temps et numérotés, ce qui permet de suivre la démarche. Dans le cas d'un seul gros patch, mettre des commentaires ou des sous-patchs pour faciliter la lecture.

Cours 07 << ~(oO) ~ >>