Les quatres groupes de livrables principaux du projet OSSIA sont des briques logicielles partageables pour l’écriture de scénarios et l’interopérabilité, leurs implémentations prototypales et une observation de leurs usages.
Le développement des briques logicielles partageables pour l’écriture de scénarios s’est scindée en deux phases :
Dans un premier temps, le moteur d’édition et d’exécution libIscore a été encapsulé dans le framework JamomaFoundation, puis partiellement réécrit pour tirer au mieux parti des fonctionnalités de ce dernier sous la forme du framework JamomaScore, sur lequel s’appuie la version 0.2 de i-score.
Dans un deuxième temps, et pour exploiter au mieux les évolutions du modèle qui ont eu lieu au cours du projet, le moteur a été entièrement ré-écrit. Cette ré-écriture s’est appuyée sur la conception préalable par le LaBRI d’une API en C++, qui expose les divers aspects des nouveaux modèles formels, tout en prenant en compte les fonctionnalités présentes dans les versions précédentes du moteur et de l’interface, dans un format plus universel et plus facile à apprivoiser que le “dialecte” de Jamoma.
Une implémentation de cette API a alors été développée en repartant de zéro afin de proposer un nouveau moteur (d’exécution seulement, la gestion de l’édition a été transférée dans l’interface) libéré des héritages techniques portés par les couches de développement accumulées au cours de plusieurs années d’ajouts et de remaniements successifs, afin de tirer le meilleur parti d’un modèle amélioré, simplifié et rendu plus générique.
Le développement des briques logicielles partageables pour l’interopérabilité s’est basé sur la création d’un framework, Modular, dédié à la gestion d’arborescences fonctionnelles dans l’environnement Jamoma.
Ce framework permet la gestion de l’adressage d’architectures de paramètres arborescentes (basées sur le nommage sur le modèle des URL par le protocole OSC), la publication de leurs structures et un système de requêtes permettant de les explorer et d’en interroger les valeurs à distance, comme une base de données dynamique.
Ce framework a été implémenté dans le moteur d’i-score, ainsi que dans tous les environnements ou applications utilisés par les praticiens associés au projet : Max, pure data, Websocket, Unity, Modul8. La majeure partie de ces implémentations font partie de la “release” de Jamoma 1.0 qui accompagne la clôture du projet OSSIA.
Par ailleurs, plusieurs acteurs du projet se sont impliqués dans la spécification du protocole de requête OSC-query qui propose un modèle plus robuste et générique que le système de requête Minuit (également basé sur OSC), développé au cours du projet Virage et employé dans OSSIA pour permettre l’interopérabilité entre systèmes.
Deux générations du séquenceur i-score ont également été produites au cours du projet :
Une première version 0.2 a été publiée vers le début du projet afin de permettre une expérimentation concrète des évolutions du modèle, qui y étaient introduites de manière incrémentale, afin que les utilisateurs puissent en éprouver concrètement les principes en situation réelle. Cette version était basée sur le moteur JamomaScore et sur des développements précédents de l’interface graphique. L’un comme l’autre montraient trop de faiblesses structurelles et étaient encombrés par le poids des couches antérieures de développement, et il a donc été décidé de les refondre tous deux entièrement pour aboutir en fin de projet à une base saine sur laquelle pouvoir engager de futures évolutions du modèle et de ses implémentations.
Un important effort de développement a donc été engagé sur le développement de i-score 1.0, par la refonte complète du moteur (comme indiqué ci-dessus) et de l’interface, raison pour laquelle nous avons du allonger le projet d’un mois. En date de la fin du projet OSSIA, nous avons abouti à un prototype opérationnel, qui a pu être mis dans les mains des utilisateurs afin d’en valider les grands principes. Le logiciel en reste cependant encore au stade de prototype (soit une version alpha) et demande encore un certain effort de développement pour pouvoir être réellement diffusé, ce que nous prévoyons de faire dans des projets de développement à venir.
Des versions embarquées de “players” de scénarios i-score ont également été produites pour la version 0.2. Elles sont disponibles sous forme d’un player standalone pour raspberry Pi, ainsi que sous forme d’externals Max et pure data, j.score, inclus dans les collections JamomaMax et JamomaPureData. Les players pour la version 1.0 sont en cours de développement, et seront publiés dans les mois à venir.
Il était prévu initialement de produire une représentation “cuelist” ou “conduite”, afin de donner une vision des scénarios synthétique et “orientée vers l’action” au moment de l’exécution (par exemple de la représentation d’un spectacle). Cette interface n’a pu être finalisée à la date de la fin de projet, car elle dépend de la disponibilité – à venir sous peu – du player i-score dans Max – elle le sera cependant dans les mois à venir par le GMEA.
Il était également prévu une représentation spatiale des scénarios. Après de nombreuses discussions, cette perspective s’est avérée bien plus riche et complexe que nous ne l’avions projeté, et a ouvert des pistes de recherche qui ont mené à la mise en place d’une thèse de doctorat joint entre Blue Yeti et le LaBRI, ainsi que le dépôt du pré-projet STIP spécialement dédié à ce sujet à la session 2015-2016 de l’AAP ANR. Néanmoins, différents travaux ont pu être menés sur cette thématique :
- un état de l’art scientifique de la représentation et de la manipulation de paramètres d’espace
- un état de l’art de la manipulation de données spatiales dans les environnements de création d’applications interactives
- une réflexion formelle sur un vocabulaire d’espace
- un chantier d’expérimentation avec un premier essai d’intégration d’interface spatiale dans i-score et le pilotage d’un moteur audio.
La documentation des prototypes et briques logicielles produits au cours du projet a été publiée, soit sur leurs dépôts pour les diverses briques, soit sur un sous-site dédié pour i-score 0.2.
La documentation de i-score 1.0 est en cours : il nous a semblé préférable d’attendre que les principaux principes d’ergonomie soient stabilisés (ce qui a eu lieu en toute fin du projet) avant d’en finaliser la rédaction. Elle sera donc publiée dans les mois suivant la clôture du projet, en même temps qu’une version bêta du logiciel.
L’observation des usages s’est faite tout au long du projet, de manière spécifique pour chacun des domaines :
- dans le domaine des jeux vidéo : une enquête au près du Syndicat National du Jeu Vidéo a été menée. Les conclusions sont jointes en annexe de ce rapport. Le CNAM a ensuite mené une expérimentation autour d’un projet concret de jeu vidéo sonore, Le promeneur écoutant, de Cécile Le Prado afin d’étudier la possibilité de le ré-écrire à l’aide d’i-score. Le compte-rendu de cette étude se trouve ici.
- dans le domaine artistique, les prototypes produits ont été utilisés dans plusieurs projets professionnels, ainsi que lors de plusieurs chantiers d’expérimentations. Un rapport de ces observations d’usages par l’ENSATT et l’ISTS se trouve ici.
- dans le domaine muséographique, un chantier d’expérimentation a été lancé afin d’évaluer l’apport du formalisme et des frameworks développés dans le cadre du projet pour la réalisation d’animations interactives. Des cas d’usage correspondant à des projets réels réalisés ou en cours (comme le projet Arena au Futuroscope) ont été identifiés et ont servi de base de réflexion pour l’implémentation des boucles et des conditions dans i-score.
Par ailleurs, l’implication concrète et soutenue des utilisateurs dans le processus, en ligne comme par leur présence lors des séminaires, a été bien plus importante qu’envisagé initialement, et a permis d’intégrer de manière plus profonde et plus organique leurs besoins et retours – en quelque sorte de “première main”, évitant ainsi la perte d’informations par une phase de transmission – dans la phase de conception même.