Les environnements logiciels et les protocoles dédiés

Il existe des Environnements Logiciels (EL) servant de socle à la conception d'application distribuée et des intergiciels spécifiquement dédiés à la RA. Aujourd'hui la recherche académique se concentre beaucoup sur les SRA décentralisés et distribués, car c'est la RA mobile (téléphones, tablettes, ect.) qui connait la plus forte croissante et des possibilités élargies d'applications par rapport à la RAS. De façon générale, cette capacité de distribution sur les couches internet permet de concevoir des applications avec un périmètre de fonctionnalités plus étendu, une architecture plus ajustable ("scalabilité"), et souvent moins chère étant donné l'accessibilité de la technologie des systèmes utilisant le protocole TCP/IP. En 2013, Chouiten a fait la comparaison des principaux EL issus de la recherche académique utilisés pour créer des applications de RA et leurs avantages spécifiques, résumées dans le tableau 2-1.

Tableau 2-1 : Comparaison des principaux EL distribués en RA (Chouiten, 2013) Nom de l'EL Modèle

d’application Facilité de programmation Mise à l’échelle Flexibilité et interopérabilité Architecture réseau DWARF Services interdépendants Outils d'édition et de monitoring, ensemble de modules prédéveloppés

Scalable Interopérable avec Studierstube, édition à l’exécution Décentralisée MORGAN Composants souscrivant à des périphériques d'entrées

Offre une API pour le prototypage rapide

Scalable Offre un proxy pour

différents protocoles

Dépend de l’application

Studierstube Application objets,

métaphore d'interaction 3D, graphe de scène. Outils de scénarisation, modèle d’application simple mais fonctionnalités limitées Scalabilite limitée Interopérable avec DWARF Centralisé Tinmith Architecture

dirigée par les données, modules interdépendants Modèle d’application simple, outil de débogage Petit nombre d’utilisateurs sur une zone étendue

Edition en runtime Client/Serveur

VARU Trois niveaux

d’abstraction pour des objets existants dans trois espaces parallèles

Outils spécifiques aux applications, quelques modules dans l’API (ex. reconnaissance de gestes)

Petit nombre d’utilisateurs

VRPN (interaction standard avec les périphériques)

Client/Serveur

Ces EL constituent autant de bonnes pistes lors de la sélection d'un outil logiciel pour la conception d'un SRA avec une architecture distribuée. Cependant, nous n'avons pas eu à les utiliser dans nos cas. Un des buts de ce projet était en effet de découvrir les outils et méthodes de conception logicielles adaptées aux besoins de l'industrie de la communication événementielle.

Nous verrons dans la suite que dans bon nombre de SRAS, c'est par simple "émulations de commandes MIDI et clavier" que nous avons assuré la dimension inter application et programmé l'intelligence de la dimension interactive des fonctions d'usages. La définition du terme émuler est "chercher à imiter". Il faut voir dans l'émulation une imitation du comportement physique d'un matériel par un logiciel, et ne pas la confondre avec la simulation, laquelle vise à imiter un modèle abstrait. Il est en effet possible d'utiliser une application spécifique, simulant pour une autre application donnée les appuis de touches dans le monde physique. L'objectif de l'émulation dans nos cas était surtout de réduire le coût associé à la dimension matérielle en faisant un routage interne au sein d'un même ordinateur plutôt qu'externe avec plusieurs ordinateurs et des boitiers d'acquisition pour la sérialisation/désérialisation des flux de communication entre les sous-systèmes de l'unité de calcul globale du SRA.

Nous présentons ci-après succinctement les protocoles de communications que nous avons utilisés et qui sont spécifiques au secteur événementiel, car cela parait essentiel à la compréhension de la description des cas et des choix de conception adoptés.

MIDI : Même s'il est originellement destiné au développement des instruments de musique numérique, le "Musical Instrument Digital Interface" (MIDI) est le protocole de communication le plus utilisé dans le secteur événementiel pour contrôler des systèmes interactifs. En effet, la plupart des serveurs multimédias du secteur événementiel (arts du spectacle et corporatif) et des EDI dédiés aux installations interactives et immersives intègrent ce protocole, ce qui permet l'échange entre différents logiciels ou tout simplement le transfert entre actions des éléments de contrôle et le système comportemental. Enfin, bon nombre de capteurs utilisés pour les installations interactives interfaces avec ce protocole, facilitant leur intégration avec les logiciels utilisés dans ce milieu. D’un point de vue technique, ce protocole ne permet qu’une liaison unidirectionnelle. Cependant, comme il existe des ports MIDI IN et MIDI OUT sur tous les équipements intégrant ce protocole, les échanges mutuels d’information sont possibles. Enfin, un autre avantage de ce protocole est la possibilité de synchroniser plusieurs ordinateurs entre eux facilement, ce qui est utile pour la mise en place d’une architecture réseau d'ordinateurs synchronisés pour les installations de grandes ampleurs.

DMX : Le DMX 512 ("Digital MultipleXing") est le protocole principalement utilisé pour le contrôle des équipements d'éclairages dynamiques. Le protocole permet de contrôler 512 canaux

en affectant à chacun une valeur comprise entre 0 et 255. La transmission se fait de façon sérialisée, c.-à-d.. en paquet d'informations, et chaque appareil reçoit en même temps l'ensemble des 512 valeurs. La norme prévoit la mise en série d'un maximum de 32 appareils sur une même ligne DMX, et l'utilisation d'un maximum de 16 canaux par appareil. Cependant, dans la pratique certains appareils utilisent plus beaucoup plus de canaux.

Art-net : Art-Net est un protocole basé sur le DMX, mais cette fois sur le réseau TPC/IP, permettant ainsi un câblage moins contraignant au niveau de la longueur maximale des câbles et/ou plus pratique en utilisant des bornes d'accès internet sans fil.

OSC : L'"Open Sound Control" (OSC) est un format de transmission de données entre ordinateurs, synthétiseurs, robots ou tout autre matériel ou logiciel compatible, optimisé pour le contrôle en temps réel via UDP. Il est de plus en plus utilisé dans les systèmes interactifs, car il permet de transmettre des informations plus riches que celles que le protocole MIDI. Une des applications principales est la transmission en temps réel d’informations spatiales sur plusieurs axes, comme la position d'un doigt sur une surface tactile pour le cas 2D. Enfin, cela permet également de se servir de périphériques tels que les téléphones intelligents ou tablettes pour les modalités d'interactions indirectes grâce à une multitude d’applications gratuites utilisant les couches réseau du web, ou encore des capteurs intégrés dans ces dispositifs, comme les gyroscopes ou accéléromètres.

Syphon : Syphon est un intergiciel disponible sur Mac OSX permettant de passer un flux vidéo entre plusieurs applications. Il permet ainsi d'acquérir une source vidéo d'un logiciel de lecture via un routage interne plutôt qu'externe avec un boitier d'acquisition. Il est souvent utilisé pour la conception d'environnement de RM dans l'industrie et la recherche (cf. Bourke, 2005, 2008) Le "pixel mapping DMX" : Le "pixel mapping DMX" n'est pas vraiment un protocole, mais cela consiste à convertir les pixels d’une image ou d’une vidéo en information de contrôle DMX.

Madmapper possède un outil permettant de faciliter cet adressage d'un pixel à un projecteur de lumière. Cela permet de créer facilement une grande variété d’effets et semble particulièrement adapté à l’utilisation de dalles de LED digitales qui à travers le contrôle des 3 couleurs primaires de chaque pixel/LED vont se comporter comme un moniteur vidéo classique.

La figure 2-12 est une illustration d'un certain nombre des périphériques d'entrées-sorties d'un SRAS du domaine événementiel et leurs moyens de communication indicatifs avec le serveur multimédia. Ce sont ceux qui ont été présentés ci-avant et utilisés dans les cas développés durant cette étude.

De façon générale, il s'agit donc de choisir un EL compatible avec les périphériques d'entrée- sortie utilisés et leurs protocoles de communication, imposés par les fabricants des dispositifs en question, et cela était contingent à l'application spécifique des SRAS développé.