IBTS-77-RP-1000
Patching
La notion de patching est relative aux activités réalisées et supportées au sein des environnements de patching. Après avoir donné une définition générale du patch, nous distinguerons les deux activités principales permises par ce type d’environnement qui sont d’une part l’activité de conception et d’autre part l’activité de jeu.
Un patch peut être défini comme un programme informatique, réalisé au sein d’un environnement de programmation graphique spécifique [Myers, 1990]. La programmation d’un patch se fait grâce à un assemblage de briques essentielles, appelées aussi objets, reliées entre elles par des liens, pour créer des traitements musicaux, ou plus généralement des processus interactifs qui peuvent être exécutés et contrôlés en temps réel au sein du même environnement.
On parle d’environnement pour désigner ce genre de logiciels dans la mesure où ils se comportent à la fois comme des éditeurs, des environnements de développement donc, et des environnements d’exécution pour les programmes créés à travers eux.
Il existe de nombreux logiciels permettant de faire du patching audio, mais les deux plus connus et utilisés aujourd’hui, et auxquels nous nous réfèrerons plus principalement dans le cadre de notre recherche, sont Max et Pure Data. Le logiciel Max est un logiciel propriétaire commercialisé par la société Cycling’74 depuis 1997. Le logiciel Pure Data est un logiciel libre, développé depuis 1996 par Miller Puckette et d’autres contributeurs [Puckette, 1997].
Collaboration
Si l’interaction se définit comme un échange entre plusieurs acteurs au sein d’un système, la collaboration peut se définir de manière générale comme une forme particulière d’interaction qui converge vers un but commun que partagent ses acteurs. Dans la littérature liée au travail coopératif assisté par ordinateur (TCAO)16 on retrouve souvent le terme groupware. Ce terme est un néologisme inventé par Peter et Trudy Johnson-Lenz en 1978 qui désigne et comprend pour eux à la fois l’ensemble des processus et procédures d’un groupe de travail devant atteindre un objectif particulier, mais aussi les logiciels conçus pour faciliter ce travail de groupe [Peter & Trudy Johnson-Lenz, 1990]. Cette définition comporte donc des composants à la fois technologiques et humains. C’est un ensemble de méthodes et de techniques de travail en équipe, instrumentées par des outils logiciels conçus spécifiquement pour les soutenir. Ce type de logiciels, qui permettent à des utilisateurs reliés par un réseau de travailler en collaboration sur un même projet, sont désignés en français sous le nom de collecticiels, mais on utilise aussi les termes de logiciels de groupe ou encore logiciel multi-utilisateur par opposition aux logiciels traditionnels destinés à n’être manipulés que par un seul utilisateur à la fois (ou mono-utilisateur).
Plusieurs outils taxonomiques et conceptuels ont été conçus pour analyser les systèmes supportant le travail collaboratif. Ces systèmes peuvent différer selon leur nature, le domaine d’application auxquels ils répondent, les types d’interaction qu’ils soutiennent ou encore le type de fonctionnalités qu’ils offrent aux utilisateurs.
Patching collaboratif
Un patch peut être vu à la fois comme un document statique (qui peut être sauvé en tant que fichier sur le disque), mais aussi comme un document dynamique dans le sens où, chargé au sein de l’environnement dans lequel il a été créé, il peut être exécuté pour créer et contrôler des processus musicaux en temps réel. Si on essaye de transposer les fonctionnalités offertes par un environnement mono-utilisateur de patching à une solution logicielle du même type, mais qui permet d’effectuer des opérations similaires à plusieurs, quels sont les objets et les données quel’on cherche à partager ? Quels types d’opérations pourraient être permises par ce système et quels types d’activités mises en commun est-on à même d’envisager qu’il puisse supporter ? Nous avons discerné deux types d’activités principales au sein de ces environnements, l’activité de conception du patch et l’activité de jeu. Dans le cadre d’une édition collaborative, les données à partager correspondent aux informations relatives au modèle du patch c’est-à-dire à sa structure. Les utilisateurs s’intéressent dans ce cas à la co-construction d’un même instrument ou plus généralement à la manière dont est mis en œuvre un traitement au sein d’un patch, on se place donc ici à un niveau algorithmique. Dans le cas d’un jeu partagé, les utilisateurs cherchent seulement à utiliser le même instrument préexistant à plusieurs, on voudra alors transmettre en temps réel l’état du programme aux autres participants et non-plus sa structure. Il existe aussi des cas intermédiaires, comme dans les pratiques de live coding, où les utilisateurs se servent de l’instrument dans le cadre d’une performance tout en le créant, en l’éditant en même temps qu’ils en jouent. Dans ce cas c’est à la fois la structure du document et son état interne que l’on cherchera à partager.
Édition collaborative asynchrone
Nous employons tous des techniques et des solutions logicielles pour collaborer avec d’autres personnes sur des projets musicaux (ou autres) dans notre pratique quotidienne. La condition préalable à toute collaboration est le partage des données. Dans le cas de l’édition collaborative asynchrone de patch, l’élément partagé entre les utilisateurs est le patch, en tant que document statique. Ce partage peut s’effectuer simplement par copie, par courrier électronique ou encore via un transfert par clef USB. Les utilisateurs disposant des mêmes données stockées au sein d’un fichier peuvent alors apporter des modifications chacun de leur côté au document. Le problème bien connu lié à ce procédé est que les modifications apportées parallèlement par les utilisateurs ne sont pas synchronisées entre-elles et on assiste alors à une démultiplication des versions du même document source, et à une perte de la notion de document référent auquel se fier. Dès lors, quelles solutions logicielles peuvent venir soutenir ces pratiques ? Une première solution consiste à centraliser l’information en ligne, c’est-à-dire le patch, de façon à pouvoir déterminer une version référente du document. Le premier cas de collaboration asynchrone que nous avons choisi d’étudier entre dans ce cadre. C’est une pratique au sein de laquelle des personnes usent d’un forum de discussion comme support logiciel permettant le partage d’un document commun pouvant être édité par plusieurs personnes. Une autre solution consiste à maintenir des copies indépendantes du document chez chacun des participants puis à les synchroniser entre-elles grâce à des outils permettant la gestion de version. Nous étudierons cette solution dans un second temps.
Édition et jeu collaboratifs synchrones
Nous nous situons ici dans les configurations décrites par la première colonne de la matrice d’Ellis, avec des types d’interaction géographiquement distribuées ou colocalisées mais se situant toutes au «même moment». Pour Ellis et Gibbs, les systèmes multi-utilisateurs en temps réel se définissent comme des systèmes où «les actions d’un utilisateur doivent être rapidement propagées aux autres utilisateurs». Selon si on se situe dans une configuration d’édition ou de contrôle du patch, les actions et donc les informations partagées, ne seront pas les mêmes. De la même manière, si les interactions s’effectuent au même endroit ou à des endroits différents, la façon de mettre en place ce partage aura aussi son importance.
Les applications de patching traditionnelles sont conçues à la base pour être utilisées dans un contexte mono-utilisateur ; des adaptations doivent donc être faites pour permettre de les utiliser dans un contexte multi-utilisateur de manière synchrone. Il s’agira alors de faire ressortir ici les choix de conception de ces différents outils, de comprendre quels types de pratiques ils permettent de soutenir et quelles sont leurs limites.
On distingue deux manières de propager les actions aux autres participants et de partager de l’information :
Le partage d’application. Il permet d’utiliser une seule et même application à plusieurs en même temps. Le traitement de l’information est alors centralisé sur l’application qui sert de lien entre les clients qui communiquent avec elle. Dans ce type d’architecture on distinguera aussi des choix de conception qui relève du partage et la réplique de la vue.
Le partage de données. Il permet à chaque participant de disposer de l’application sur sa propre machine. Les données doivent alors être partagées et synchronisées entre chaque application client.
|
Table des matières
Introduction générale
Partie I – Présentation, étude et formalisation des enjeux
1. Aperçu général du sujet
1.1. Patching
1.1.1. Définition
1.1.2. Activités de conception et de jeu
1.2. Collaboration
1.2.1. Types d’interaction
1.2.2. Espaces de production, de coordination et de communication
1.3. Patching collaboratif
2. Études des pratiques et solutions logicielles existantes
2.1. Édition collaborative asynchrone
2.1.1. Cas d’étude du forum en ligne
2.1.1.1. Hippie patching
2.1.1.2. Gestion d’une ressource commune
2.1.1.3. Documentation des actions
2.1.1.4. Gestion de la concurrence
2.1.1.5. L’apprentissage induit par la pratique
2.1.1.6. Bilan de l’étude sur le forum
2.1.2. Le contrôle de version
2.1.2.1. Définition
2.1.2.2. Limites du système
2.1.3. Bilan de l’étude des solutions de collaboration asynchrone
2.2. Édition et jeu collaboratifs synchrones
2.2.1. Édition collaborative synchrone
2.2.1.1. Edition colocalisée
2.2.1.2. Édition distribuée
2.2.2. Jeu collaboratif synchrone
2.2.2.1. Jeu colocalisé
2.2.2.2. Jeu distribué
2.3. Bilan de l’étude des pratiques et solutions logicielles existantes
3. Formalisation des enjeux
3.1. Caractéristiques des systèmes synchrones
3.2. Réplique des données
3.3. Contrôle d’accès
3.4. Gestion des sessions
3.5. Gestion des conflits et contrôle de la concurrence
3.6. Mécanismes de conscience de groupe
3.7. Contexte spécifique par utilisateur
3.8. Vers une nouvelle solution collaborative de patching
Partie II – Présentation et mise en œuvre de l’application Kiwi
4. Conception de l’espace de production
4.1. Choix généraux du langage Patcher de Kiwi
4.1.1. Objets disponibles
4.1.2. Éléments graphiques
4.1.3. Spécificités fonctionnelles
4.2. Modélisation et architecture logicielle
4.2.1. Modélisation du patch
4.2.2. Architecture de l’application client
4.2.3. Architecture client-serveur
4.3. Opérations
4.3.1. Mode de jeu et mode d’édition du patch
4.3.2. Instanciation des objets dans un patch
4.3.3. Raccordement des objets
4.3.4. Contexte local de visualisation du patch
4.3.5. Contexte local d’exécution du patch
4.4. Autres composants de l’espace de production local
4.4.1. Console
4.4.2. Beacon Dispatcher
4.4.3. Préférences audio
5. Conception de l’espace de coordination
5.1. Coordination de l’espace de travail partagé
5.1.1. Conscience de connexion et de présence des utilisateurs au sein de l’espace partagé
5.1.2. Conscience de l’activité d’édition du patch par le groupe
5.1.3. Relâchement du principe de WYSIWIS sur le temps d’affichage
5.1.4. Contexte local d’annulation et de restauration des actions
5.1.5. Gestion des conflits et validation du modèle de données
5.1.6. Mise en place d’animations
5.2. Gestion des sessions
5.2.1. Une première solution décentralisée
5.2.2. Passage à une gestion de sessions centralisée
5.2.2.1. Configuration des options liées au réseau
5.2.2.2. Enregistrement et authentification
5.2.2.3. Gestion des documents distants
5.2.3. Notifications et gestions des erreurs de connexion
6. Conception de l’espace de communication
6.1. Présentation et mise en œuvre de l’objet hub
6.2. Utilisations de l’objet hub
6.2.1. Synchronisation de valeurs de jeu
6.2.2. Création d’un mécanisme de discussion instantanée
6.2.3. Obtention du nombre d’utilisateurs connectés au sein du patch
Partie III – Retours d’utilisation et perspectives
7. Premières utilisations du logiciel
7.1. Festival la DéMO
7.2. Cours pilote avec Kiwi à l’Université Paris 8
7.2.1. Contexte
7.2.2. Premiers tests
7.2.3. Reconfiguration des usages
7.2.4. De nouvelles interactions
7.2.5. Communication inter-utilisateur
7.2.6. Premiers retours
7.3. Représentations musicales
7.3.1. Pièce mixte avec contrôle collaboratif du patch
7.3.2. Limites de l’approche
7.3.2.1. Représentation des actions de jeu
7.3.2.2. Latence du système
7.4. Présentations et ateliers
7.5. Intégration future de Kiwi dans un MOOC
8. Perspectives
8.1. Intégration du langage Faust
8.1.1. Enjeux et pistes de recherche
8.1.2. Présentation et mise en œuvre de l’objet faust~
8.2. Conscience de groupe
8.2.1. Partage du pointeur de souris
8.2.2. Vue en radar
8.2.3. Conscience du changement
8.2.3.1. Quels changements ?
8.2.3.2. Capture et stockage des informations
8.2.3.3. Représentation des changements
8.3. Gestion des sessions
8.3.1. Amélioration de l’interface de gestion de sessions
8.3.2. Vers un espace personnel et un contrôle d’accès aux documents
8.3.3. Gestion d’un mode hors-connexion
8.4. Jeu collaboratif
8.4.1. Du partage de données au partage de fonctionnalités
8.4.2. De nouvelles interfaces dédiées
8.4.3. Stockage de valeurs
Conclusion générale
Bibliographie
Télécharger le rapport complet
