Les outils 3- prospectives de développement :

Protocole d'échange

Nous avons déduit des réflexions précédentes qu'il semblait plus productif de s'orienter vers l'établissement d'un protocole plutôt que d'un produit fini : Le développement devrait privilégier un environnement ouvert, évolutif, tout en proposant des éléments d'assez haut niveau pour ne pas exiger de l'utilisateur des compétences trop élevées de programmation.
Ainsi peut-on éviter le risque majeur du produit fini : devenir obsolète au moment même où il est produit, puisque ne pouvant suivre l'évolution vertigineuse des pratiques.

Nous nous sommes donc orientés vers des communautés de travail ayant des objectifs similaires :

- Jamoma, dont l'objectif est de "produire une structure pour l'échange, la réutilisation et la transmission de patches Max". L'une des particularités intéressantes de ce système est son usage du protocole OSC.
Nous avons donc organisé une rencontre avec Trond Lossius, un des fondateurs de cette initiative, qui nous en a expliqué le fonctionnement et l'esprit, qui se trouvaient converger sur de nombreux points avec notre démarche.

- Nous avons également participé à une réunion de travail du groupe Integra, dont certains des objectifs sont similaires aux nôtres, à savoir la réflexion sur le développement d'un environnement audio basé sur le couple interface/moteur, mais dans un champ différent : la pérennisation et la création d'oeuvres musicales contemporaines "mixtes" (instrumentales et électroniques).
À noter que Integra et Jamoma réfléchissent ensemble à l'élaboration d'un espace de nommage générique, visant à la description des processus audio et des modes d'interaction, et basé sur le protocole OSC

- Nous avons enfin assisté à la réunion des développeurs OSC qui a eu lieu à l'IRCAM, à la fin du NIME'06. Cette réunion évoquait notamment l'élaboration d'un OSC 2.0 (sur le modèle du web 2.0), dont l'une des particularités intéressantes consisterait à ce que les systèmes soient dotés de dispositifs permettant de s'identifier lorsqu'ils apparaissent sur un réseau, et de signaler leur arborescence et, partant, les langages qu'ils comprennent et produisent, c’est-à-dire leurs modes de description des données et leurs structures d'adressage. Cette évolution permettrait notamment de régler le principal problème actuel du protocole OSC, à savoir sa trop grande ouverture.

Niveaux d'utilisateurs

Il nous a semblé pertinent, dans la perspective d'un développement futur d'un tel système, de dégager trois niveaux d'utilisateurs :

- Utilisateur final : Régisseur, compositeur n'ayant pas ou peu de connaissance de la programmation informatique, et dont l'intérêt se situe dans la mise en oeuvre du sonore pour la composition et la régie. Cet utilisateur est cependant censé avoir consacré un minimum de temps à se former à l'utilisation de l'environnement, qui doit rester suffisamment ergonomique et clair pour en permettre une prise en main en quelques heures, même si l'exploitation de toutes les possibilités impliquerait forcément d'avantage d'exploration.

- Développeur de modules : Compositeur ou régisseur ayant une certaine expérience de la programmation, et souhaitant intervenir sur les processus et algorithmes mis en jeu. Il faut alors fournir à cet utilisateur "intermédiaire" un "Software development kit" simple d'utilisation et clair, lui permettant dans un temps relativement court d'intégrer ses algorithmes comme de nouveaux éléments de la librairie de modules, sans forcément avoir à connaître ou comprendre le fonctionnement interne de l'environnement.

- Développeur d'environnement ou de moteur : Membre d'une équipe de développement d'environnement, il est censé connaître la majeure partie des tenants et aboutissants de la programmation de l'environnement et en assurer la maintenance et l'évolution. Il est en dialogue avec les développeurs de modules et leur fournit une "feuille de route" pour l'intégration de leurs modules.