Données enregistrées - Utilisation

Une fois que nous avons des fichiers txt contenant des données de capteurs, qu'en faire ?

Il y a deux façons d'enregistrer et de rappeler des données :

  • Gérer les capteurs au fur et à mesure que le dispositif évolue, en déclenchant manuellement la lecture des données au moment opportun.
    • Ce choix implique des enregistrements courts, sur un capteur, d'un événement, qui peut être appelé plusieurs fois, à la volée.
    • C'est un comportement dynamique, qui permet de s'adapter à un dispositif imprévisible.
  • Gérer l'ensemble du dispositif comme une démonstration continue automatisée
    • Ce choix implique d'enregistrer une séquence longue, avec un ou plusieurs capteurs, avec des comportements dans un ordre précis.
    • Il n'y a pas d'intervention manuelle au cours de la démonstration, ce qui peut être intéressant pour une simulation réaliste.

Les deux solutions sont intéressantes, et selon les projets l'une est mieux que l'autre.

La banque de données de capteurs en fichiers txt comporte plutôt des enregistrements courts, mais il y a aussi des séquences (par exemple plusieurs mouvements devant un pyro) ou des combinaisons de capteurs (les capteurs de flexion de gants).

Déclenchement à la volée, capteur par capteur

Déclenchement dans le patch à la souris

Ce n'est qu'une étape...

Reprenons l'exemple de la Belgariade.
Une autre possibilité est de lancer une à une les étapes en appelant des fichiers spécifiques pour chaque capteur. Cela permet de s'adapter en direct à l'évolution du projet.

utilisation du mtr

Nous utilisons ici 4 fichiers de données enregistrées, 2 par capteur :

  • pyro_1fois.txt
  • pyro_plusieurs.txt
  • proxi_tres_lent.txt
  • proxi_rapide_plusieurs_fois.txt

A chaque fois, les données sont appelées avec un Button bang, suivi d'un trigger b b, qui tape d'abord dans le message read du fichier txt, puis qui lance la lecture sur play.

J'ai utilisé 2 objets mtr différents afin de simplifier l'envoi de la sortie vers les traitements spécifiques de chaque capteur.

Télécharger le patch exemple : belgariade_playback_mieux.zip, zip contenant les données en txt aussi.

Inconvénients

  • Manque d'ergonomie : c'est pratique en cours de dévelppement pour faire quelques tests, mais c'est très maladroit pour une démonstration de chercher des zones à cliquer à la souris.
  • Impossibilité d'afficher un rendu final plein écran.

Déclenchement mieux : par touches de clavier

Plus pratique et plus ergonomique pour une démonstration : chaque enregistrement est associé à une touche de clavier, avec l'objet key suivi d'un sel.
Voir les pages :
La chaise, capteur en playback
Devil in the dark playback

Simulation complète

Cette méthode n'est pas compatible avec des improvisations en temps réel.

Les deux capteurs ont été enregistrés ensemble et décalés au cours du temps, en 1 fichier ce qui permet de faire une démonstration sans devoir rien toucher en même temps.
C'est le même exemple qui était utilisé dans la première page de ce chapitre pour l'enregistrement général des capteurs.

Cette démarche est intéressante pour des dispositifs musicaux par exemple.

Patch en simulation

Le patch est fourni avec un fichier capteursbelgariade.txt qui contient la séquence d'actions sur les deux capteurs.

Pour faire fonctionner la démo en playback, sans modifier les données des capteurs :

  • Clic sur read (6)
  • Choisir capteursbelgariade.txt
  • Clic sur le play jaune général (7)
  • ... ou mettre cette séquence directement sous le loadbang avec un t b b b .

Dans ce patch, tous les capteurs sont enregistrés en même temps, ce qui permet de décaler dans la lecture le capteur de distance après le capteur de mouvement.

Télécharger le patch exemple : cf page Multitrack Recorder en bas.