Concevoir un programme de captation, suivi et traitement sonore du geste instrumental

Des usages multiples du patch

 Pendant la phase de recherche

On peut apporter plusieurs explications sur l’analyse nécessaire de données nombreuses et variées des capteurs :

Lors des premières séances de recherche (fin 2006, début 2007), les données de capteurs et le signal audio sont enregistrés en double :

Puis Digital Performer ne sera plus utilisé, une fois que le système de sauvegarde dans Max/MSP sera sûr et fonctionnel. Le chercheur en informatique musicale a amélioré le système de nommage des enregistrements à l’aide d’un système mixte composé d’un nom libre (‘gamme’, ‘section-G’ …) et d’un nombre qui s’incrémente automatiquement et que le chercheur réinitialise à 1 pour chaque nouvelle figure musicale.

Copie d'écran d'un repertoire de sauvegarde d'une séance d'expérimentation.
Pour chaque enregistrement, le patch sauvegarde un couple fichier audio (format aif) - fichier de données des capteurs (au format txt).

Dans un second temps, le chercheur en informatique musicale rend possible la relecture dans le patch de tous les enregistrements de toutes les séances comme on le voit sur la figure ci-dessous avec les dates des séances d'expérimentation en studio 02-04, 06-03, 13-02 correspondant respectivement aux séances des 2 avril 2007, 6 mars 2007 et 13 février 2007. Pour naviguer aisément dans ces données nombreuses et variées, il y a d’abord eu la nécessité de lire de façon synchronisés des fichiers enregistrés de manières techniques différentes.

Frédéric Bevilacqua : [...] j’ai fait un module pour pouvoir lire toutes les sessions facilement dans un même patch, parce qu’ils n’avaient pas été enregistrés avec le même format et qu’ils n’avaient pas le même instrument et que parfois le fichier audio 1 c’était le violon puis une autre séance l’alto. J’ai refait un patch dédié pour chaque session, comme ça tout est en ordre et je peux accéder toutes les sessions en principe.
Entretien patch – 18 mai 2007

Florence Baschet a beaucoup utilisé cette fonctionnalité dans les compte-rendus des séances d'expérimentation.
Frédéric Bevilacqua a cherché à simplifier la relecture de données au maximum, même si elle ne servira pas lors de l’exécution de l’œuvre en concert : c’est à l’aide de ce dispositif simplifié d'observation des données enregistrées qu’il compte améliorer son patch.

Copie d'écran du patch permettant de relire les données enregistrées des séances du 2 avril 2007, 6 mars 2007 et 13 février 2007

Puis, pour des questions de praticité, Frédéric Bevilacqua a du rendre possible la lecture à n’importe quel instant de l’enregistrement. C’est la tâche d’un module qui synchronise le fichier de données des capteurs et le fichier audio à partir d’un fichier de synchronisation contenant des impulsions à 200 Hz (soit un échantillonnage des données des capteurs toutes les 5 millisecondes).

Frédéric Bevilacqua : La synchronisation est différente [selon les sessions], ici j’ai fait un petit truc [montre une fenêtre] : la session 45 est divisée en 8 parties et là je peux aller directement à certaines parties. Là si je rajoute un indice 45 2 [N.D.A : session 45, 2eme partie], il va me lire cette valeur [montre la fenêtre] et il démarre depuis 29522 ms. L’idée, c’est comme on a fait beaucoup de données, on les analysé une partie en faisant des Plots [logiciel permettant d'afficher des courbes, ici des courbes des données des marqueurs], une autre partie en faisant dans Max, et je pense qu’il y a encore beaucoup de choses différentes à faire et je pense que c’est bien d’avoir quelque chose qui permette de relier toutes les données à tout moment et d’essayer différentes choses. J’ai aussi fait un système de calibration, que j’avais pas eu le temps d’essayer la dernière fois. En gros je peux calibrer toutes les données d’accélérations du gyroscope en faisant ‘calibrate’ [fonctionnalité du patch] et il met la moyenne du signal à 0.5. et là j’ai plusieurs calibrations possibles que je peux rappeler avec ce truc, et donc a chaque session je peux rappeler une calibration. Pour les accéléromètres,  giroscope, c’est assez constants les sessions, par contre la pression ça bouge beaucoup.
Entretien patch – 18 mai 2007

Le passage de la phase de recherche à la phase de production

Simplification de l'interface graphique

Lors du transfert du développement du patch du chercheur en informatique musical au RIM, Frédéric Bevilacqua va « nettoyer » son patch afin de ne laisser visible que des éléments d’interface utiles au suivi de geste, et donc, compacter en sous patch (ie. patch non visible d’arrière plan) une grand nombre d’éléments de l’interface initiale dont Serge Lemouton ne se servira pas à priori. Frédéric Bevilacqua masque les éléments qu’il juge inutiles au RIM (rappelons que Serge Lemouton était souvent présent pendant la phase exploratoire et donc connaît le patch qui lui est remis). Dans Max/MSP, plusieurs possibilités sont offertes pour simplifier l’interface graphique (par ordre de complexité de développement) :

Il s’agit de transformer en boîte noire la partie suivi de gestes et de présenter simplement des entrées et sorties utiles au RIM pour son travail sur la partie transformations sonores. On est ici en présence d’une simplification du patch.

Les données utiles pour les transformations sonores

Ce moment de passage entre la phase de recherche et celle de production est aussi le moment ou Florence Baschet va travailler sur les transformations sonores avec Serge Lemouton . Dans l'entretien du 30 Octobre 2010, Florence Baschet indique à Serge Lemouton qu'elle a besoin d'avoir dans le patch de transformations sonores les données des capteurs afin de moduler parfois les effets en fonction des données gestuelles. Le chercheur en informatique musicale et le RIM se mettent alors d'accord sur la manière de router les données des capteurs depuis la partie suivi de geste du patch à la partie transformations sonores. Il y a 2 ordinateurs, 1 pour le suivi de geste et 1 pour les transformations sonores. Initialement, le premier ordinateur indiquait simplement les changements de geste repérés, soit un évènement toutes les secondes au maximum. A présent, il faut que les données des capteurs transitent entre les 2 ordinateurs, puisque c'est eux qu'utilise Florence pour moduler les effets. C'est le protocole UDP qui est utilisé pour acheminer les données entre les deux ordinateurs.

Pendant la phase de production

On observe dans ces différentes phases de développement la volonté de la part des deux développeurs du patch Frédéric Bevilacqua et Serge Lemouton :

C’est au cours de cette phase que le développement des transformation sonores va être abordé techniquement. Il s’agit pour le RIM de développer de manière définitive les transformations sonores qui seront utilisées le jour du concert.

L’une de ces transformations est une simulation d’amplificateur, réalisée à l’aide du logiciel AmpliTube™. Serge Lemouton, avançant des arguments de pérennité de ce développement, a voulu redévelopper la simulation d’enceinte utilisée initialement dans AmpliTube™ : cette entreprise commerciale pourrait un jour ‘couler’. Malheureusement, le reverse engineering n’a pas convenu à la compositrice qui préférait la simulation proposée par AmpliTube™. Quelle est la pérennité d’un développement copiant celui du produit commercial AmpliTube™ ? Pérennité qu’il faut mettre en regard du logiciel Max/MSP dans lequel se fait le développement et qui est aussi un produit commercial, bien qu’initialement développé à l’Ircam et outil principal de travail des RIM. N’ayant pas réussi à faire une rétro-ingénierie sur cette simulation, Serge Lemouton essaiera plus tard d’assurer la pérennité de son système d'une part en indiquant dans la fenêtre  principale du patch le type d’enceinte utilisée (cf figure ci dessous « ampliTube2 British Tube Lead 2 pour section A-F-H-I-J ») et d'autre part en précisant dans la documentation finale de StreicherKreis « Load the 3 presets in the AmpliTube™ vst plug-in located in the distorsion subpatcher » (ce qui précise le type d’enceinte qui a été utilisé comme filtre sonore dans AmpliTube™, afin de pouvoir retrouver ce matériel le cas échéant).

Cependant, l'intégration des traitements sonores ne va pas dans la pratique jusqu’à développer des composants déjà existants (malgré la tentative de refaire l’effet AmpliTube™). La notion de pérennité est évoquée par le RIM et par le chercheur en informatique musicale, mais non dans les mêmes termes.