Vers une nouvelle solution collaborative de patching

Nous avons fourni dans cette première partie de mémoire un aperçu général du sujet afin de définir notre objet d’étude et d'offrir des jalons conceptuels permettant d'analyser et de classer les systèmes multi-utilisateurs. Nous avons ensuite étudié en détail une série de pratiques collaboratives utilisant les environnements logiciels actuels de patching audio. Cette étude a alors fait émergé certaines problématiques, notamment techniques, relatives à la conception des outils existants qui se proposent de les soutenir. Nous avons alors tenté de regrouper et de formaliser les différents enjeux liés à la conception d’une application collaborative de patching audio dans cette dernière partie. Aussi, quel bilan peut-on tirer de ces enseignements ? Et quel type de solution logicielle souhaitons-nous créer au regard des enjeux artistiques et pédagogiques spécifiques du projet MUSICOLL ?

Le premier constat que nous pouvons dresser à la lumière des différents outils précédemment étudiés est qu’aucune des solutions existantes n’est assez flexible pour soutenir l’ensemble des pratiques collaboratives. C’est-à-dire servir à la fois d’écrin pour l’activité d’édition et de contrôle du patch, mais aussi supporter une interaction qui pourrait se faire à la fois de manière synchrone ou asynchrone, colocalisée ou géographiquement distribuée. D'un côté, les solutions asynchrones sont limitées à l'activité d'édition du patch et ne permettent pas de se retrouver au sein d’un même espace de travail pour collaborer en temps réel. De l’autre, les solutions synchrones ne permettent pas la conception collaborative de patch en temps différé. Les utilisateurs sont obligés de se trouver au même moment sur le logiciel pour pouvoir y travailler

de concert, et aucun système de sauvegarde des documents en ligne ne permet de retrouver les patchs à des moments différents. Il nous semble aussi ressortir de cette étude que l’ensemble des solutions logicielles disponibles pour le patching collaboratif synchrone ont été créées spécifiquement à destination du jeu et de la performance collective en temps réel. Les pratiques de live coding avec peerdata [Zmölnig, 2007], [Pd~Graz, 2009], ou encore de jam session avec

netpd [Haefeli, 2013] s’inscrivent par exemple entièrement dans ce type de démarche. Il existe néanmoins d’autre cas d’usage où l’aspect de conception collaborative d’un patch peut primer sur la dimension de jeu collaboratif.

Dans le cadre d’un cours d’initiation à la programmation temps réel traditionnel – tel qu’il est par exemple dispensé à l’Université Paris 8 avec des logiciels comme Pure Data ou Max comme support – on enseigne, entre autres, les processus sous-jacents aux traitements sonores, leur généralisation en quelque sorte. Cette transmission a évidemment pour but final d’amener les étudiants vers l’activité de création musicale, néanmoins elle passe essentiellement par l’activité intermédiaire de conception de l’instrument numérique. On cherche à transmettre le

principe d’une modulation de fréquence, comment on construit un flanger, un traitement de

granulation, comment ils peuvent être utilisés mais aussi comment on les fabrique, c’est-à-dire la manière dont ils peuvent être mis en œuvre, l'algorithmique qui leur est propre. L’exécution du patch ou de l’instrument créé, son rendu sonore au moment du cours, est alors placé au second plan. Il sert seulement à appuyer le propos en illustrant de manière sonore les potentialités musicales de l’instrument. Bien souvent, les étudiants ont envie de s’approprier le traitement ou le procédé mis en œuvre au sein du patch en le testant par eux-mêmes avec leurs propres fichiers sons en entrée ou en ajustant comme ils le souhaitent les différents paramètres de contrôle. Et pour cela, ils tentent de reproduire sur leurs propres machines le patch que le professeur élabore devant eux. Cependant ils abandonnent fréquemment cette tâche en raison

de la rapidité et la dextérité nécessaire à son exécution. L’enjeu d’une nouvelle solution de patching audio, qui puisse soutenir l’activité d’édition collaborative de patch dans le cadre d’un cours, était donc de rendre en ce sens les étudiants plus actifs en leur permettant d’interagir directement sur le traitement sonore et favoriser ainsi l’apprentissage par le faire-ensemble. Lorsque nous avons imaginé la solution optimale qui viendrait soutenir cette pratique, nous nous sommes rendu compte que l’exécution du traitement devait rester locale et que les valeurs des différents paramètres de jeu ne devaient pas forcément être partagées de manière systématique et automatique entre tous les collaborateurs au sein d’un patch. C’est, dans ce cas précis, l’activité de lutherie numérique que l’on cherche à partager et non pas prioritairement l’activité de jeu sur l’instrument créé, même si elle est nécessaire dans un second temps. D’autre part, cette solution devait se situer dans les quatre quadrants de la matrice d’Ellis [Tableau 1, p. 29], ceci pour répondre notamment à des cas d’usage et d’interaction bien précis et diversifiés :

• Synchrone et colocalisé : les étudiants sont réunis en même temps et au même endroit

comme en cours. Ils peuvent interagir en temps réel sur les patchs de leurs pairs ou sur celui qu’expose le professeur. Ce dernier peut aussi aider les étudiants en se connectant directement à leurs patchs ou encore exposer une difficulté rencontrée par un groupe d’étudiant sur un patch spécifique à l’ensemble de la classe en le projetant sur un écran.

• Synchrone et distribuée géographiquement : les étudiants sont réunis en même temps

mais à des endroits différents pour des séances de travail à distance avec le professeur ou entre un groupe d’étudiants. Ils peuvent interagir en temps réel et à distance sur les patchs de leurs pairs ou sur celui qu’expose le professeur.

• Asynchrone et colocalisé : un étudiant absent durant une séance de cours peut poursuivre un travail entamé précédemment et s’apercevoir des modifications apportées aux documents par d’autres collaborateurs durant son absence.

• Asynchrone et distribué géographiquement : les étudiants sont à des endroits différents

et à des moments différents. Ils peuvent, suite au cours en présentiel, reprendre chez eux ou ailleurs leur travail sur les patchs ou permettre au professeur d'accéder à distance à leurs travaux.

L’autre constat que nous pouvons faire au regard des différentes solutions existantes étudiées porte sur la diversité des choix techniques et des architectures mises en place par les différents projets, mais surtout de leur impact sur les fonctions qu’elles permettent d’offrir ou non aux utilisateurs. L’enjeu technique principal lié à la conception d’une nouvelle solution collaborative en temps réel que nous avons pu dégager dans ce chapitre semble être de pouvoir disposer d’une solution qui permette la réplique des données et non pas simplement un partage d’application. Ce type d’architecture apparaît en fait comme la condition initiale à la résolution des autres problématiques qui sont, par exemple, le fait de devoir fournir des éléments

permettant une conscience de groupe, de réduire les problèmes de latence liés à des temps de

réponse trop élevés et de fournir un contexte spécifique par utilisateur (à la fois au niveau du rendu graphique et sonore). La seule solution qui met en œuvre ce type d’architecture

actuellement (sans forcément répondre aux autres enjeux) est netpd. Cette solution comporte

l’avantage de pouvoir continuer à se servir de l’application Pure Data sans avoir à la modifier pour effectuer une performance musicale collective en réseau. Or cette solution n’est pas du tout conçue pour supporter l’activité de conception d’un patch de manière collaborative en

temps réel, et supporte encore moins la collaboration asynchrone. Dès lors, le fait d’envisager une nouvelle solution pour la soutenir apparaissait d’autant plus nécessaire.

Comme le note très justement M. Puckette, « nous sommes aujourd’hui tiraillés entre la volonté de dépasser les limites de ce qui se fait en matière de logiciel (ce qui implique vraisemblablement de trouver des solutions novatrices et originales aux problèmes) et le besoin de stabilité au niveau des outils (qui permettrait de préserver notre stock de documents

électroniques, œuvres d’art y compris) »87. Le point sur lequel met ici l’accent l’auteur du

logiciel Pure Data est celui de la pérennité, à la fois des logiciels eux-mêmes mais aussi des documents qui ont été construits avec. Aussi nous a-t-il fallut évaluer au début du projet si le besoin en matière d’innovation, qui se traduisait pour nous dans l’apport d’une dimension collaborative aux logiciels de patching traditionnels, était supérieur à celui de la préservation de l’existant. Cette première partie nous a permis de nous apercevoir qu’aucune solution n’était actuellement disponible pour supporter des fonctions d’édition collaborative distribuée et synchrone de patch. Deux possibilités s’offraient alors à nous en début de projet : partir d’une solution de patching existante puis l’adapter, ou bien développer notre propre solution en repartant de zéro.

La possibilité de partir du logiciel Max pour y apporter des modalités collaboratives à tout de

suite été exclue du fait de son caractère propriétaire qui nous aurait empêché d’accéder à ses fondements pour y effectuer les modifications nécessaires. D’autre part, ce logiciel n’est pas

multiplateforme88, ce qui représentait une des spécifications initiales à la solution que nous

87 [Puckette, 2009], p. 195.

voulions développer dans le cadre du projet MUSICOLL. L’approche consistant à partir du logiciel Pure Data pour y effectuer des modifications a en revanche été envisagée car elle

présentait de réels intérêts. Cette approche aurait alors consisté à effectuer un fork89 du logiciel

libre Pure Data puis d’effectuer des modifications à son code source. Elle nous aurait permis de bénéficier d’une communauté d’utilisateurs déjà présente et conséquente réunie autour du logiciel ; de maintenir une rétrocompatibilité des documents existants ; de bénéficier des fonctionnalités essentielles déjà mises en œuvre ; et, dans une démarche allant dans le sens de

la création de logiciel open-source, de pouvoir à la fois contribuer au code source original et de

bénéficier en retour des apports des contributeurs actifs du projet, ce qui aurait ainsi pu améliorer la pérennité des différents développements. Elle n’a néanmoins pas été retenue, ceci pour plusieurs raisons. Le développement d’une solution de patching collaborative telle que nous l’envisagions aurait impliqué de faire de nombreux changements, notamment au niveau du noyau fonctionnel du logiciel, de son interface graphique. D’autre part nous souhaitions aussi revoir certains éléments du langage pour l’adapter à un contexte pédagogique. Ces choix auraient alors dû être discutés avec la communauté de développeurs existante sur le logiciel, qui ne les auraient alors pas forcément validés, freinant d’autant le développement et nous amenant alors à devoir maintenir une version détachée de la solution Pure Data qui aurait alors

été dans le sens inverse des intérêts en matière de pérennité exposés plus haut90. Maintenir une

rétrocompatibilité avec les documents préexistants aurait aussi représenté une réelle contrainte de développement qui nous aurait empêché d’apporter tout changements radicaux au niveau du

89 Un fork, dans le domaine du développement logiciel provient d’une scission d’un projet initial, partageant avec lui une partie de son code source.

90Pd-Extended (https://puredata.info/downloads/pd-extended, consulté le 04/09/18), qui a longtemps été un fork

très utilisé du logiciel Pure Data est aujourd’hui un projet considéré comme obsolète qui n’est plus maintenu depuis plus de cinq ans. Il représente en ce sens une illustration de ce qui nous paraît être un écueil notoire lié à ce type d’approche.

langage au sein du patch ou du logiciel de manière générale. D’autre part, l’analyse du noyau de Pure Data et de son interface graphique effectuée par l’équipe, notamment à l’occasion du projet de développement HOA [Guillot, 2014], nous avait amené au début du projet à la conclusion que beaucoup de choses demanderaient à être revues au niveau de son code source si nous l’utilisions91.

Pour l’ensemble de ces raisons, mais aussi dans une démarche d’autoformation par la recherche et le développement, le choix a donc été fait de créer une nouvelle solution en partant de zéro, pour faire face aux différents défis techniques rencontrés dans cette première partie de mémoire, et répondre de manière prioritaire aux enjeux en matière de pédagogie, à savoir ceux de l’élaboration collaborative de traitements sonores. Dans la prochaine partie de ce document, nous présenterons donc cette nouvelle solution logicielle et donnerons les détails de sa mise en œuvre.

91 Les éléments bloquants étaient, de manière non-exhaustive, le fait qu’il n’y avait pas de support pour le multi-instance (il était alors prévu au début du projet que l’application puisse être intégré sous la forme d’un plugiciel à des stations de travail audionumériques), que les opérations d’undo/redo étaient limitées à une seule action, que le code était en langage C et que celui-ci était peu documenté ou encore le fait que l’interface graphique soit mise en œuvre avec le langage de script Tcl/Tk (https://www.tcl.tk/ [consulté le 05/09/18]) aujourd’hui de moins en moins adapté à la création d’interfaces graphiques modernes. Notons néanmoins que ce constat a été établi au début du projet il y a de ça plus de quatre ans, et que beaucoup de choses ont depuis été améliorées ou sont en cours d’amélioration au sein de Pure Data ou par différents projets connexes. Le support du multi-instance et de l’undo/redo illimité est actuellement en cours d’intégration au sein de Pure Data. Des forks de Pure Data tels que

Spaghettis (https://github.com/Spaghettis/Spaghettis [consulté le 05/09/18]) visent à l’amélioration de la documentation du code, enfin d’autres comme Purr Data (https://github.com/agraef/purr-data [consulté le