FR 3023026 A1 20160101 FR 1456101 A 20140627 Procédé de commande d'au moins un objet multimédia basé sur des réseaux de pétri hiérarchiques à flux temporisés L'invention a pour domaine technique la commande de systèmes interactifs multimédia. I-score est un séquenceur permettant la composition et l'exécution de scénarios multimédia interactifs. Il utilise des Réseaux de Petri hiérachiques à flux temporisés (acronyme anglais HTSPN pour « hierarchical temporized stream petri nets ») pour modéliser les partitions (calculs) exécutées. Désormais, les compositeurs (artistes) sont confrontés à des scénarios multimédias mettant en oeuvre des données de plus en plus complexes qu'ils doivent pouvoir modéliser et manipuler (modifier). Jusqu'à présent, le formalisme HTSPN ne permettait pas de manipuler ces données. Un objet de l'invention est un procédé de détermination d'au moins un signal de commande à destination d'au moins un objet multimédia en fonction d'au moins un signal d'entrée provenant de capteurs ou de mémoires informatiques comprenant au moins un fichier informatique. Le procédé comprend une étape au cours de laquelle on détermine au moins un signal de commande en fonction d'au moins un signal d'entrée et d'au moins une loi de commande mémorisée basée sur des réseaux de pétri hiérarchiques à flux temporisés, une loi de commande comprenant au moins une relation entre au moins deux signaux parmi les signaux d'entrée et les signaux de commande. Les relations peuvent être exécutées en fonction de leur hiérarchie. Une relation peut être apte à réaliser des opérations de traitement du signal sur au moins un signal d'entrée et/ou au moins un signal de sortie. Une relation peut être apte à combiner au moins deux signaux parmi les signaux d'entrée et les signaux de commande, afin de déterminer au moins un signal de commande. Une relation peut être apte à extraire au moins un attribut d'au moins un signal pour l'appliquer à au moins un autre signal, un attribut étant choisi parmi l'amplitude, la fréquence et la forme d'un signal. Une relation peut comprendre une durée pendant laquelle la relation est réalisée. La durée d'une relation peut être modifiée en fonction de conditions dépendant d'au moins un signal d'entrée et/ou de commande. Une loi de commande peut comprendre une durée de temporisation entre l'exécution d'une relation et l'exécution d'au moins une autre relation. La durée de temporisation peut être modifiée en fonction de conditions dépendant d'au moins un signal d'entrée et/ou de commande. L'unité de temps d'une loi de commande peut être égale à une trame. Par trame, on entend une suite d'au moins un échantillon d'un flux, notamment audio ou vidéo. Une loi de commande peut comprendre au moins un signal de commande mémorisé émis en fonction d'une référence temporelle absolue. Les capteurs peuvent être des capteurs de lumière, des dispositifs d'acquisition de vidéo, des capteurs de son, des dispositifs d'acquisition sonore, des capteurs de toucher, des capteurs de mouvement. Les objets multimédia peuvent être des émetteurs de lumière, des dispositifs d'affichage ou de projection vidéo, des émetteurs de son, des dispositifs de diffusion musicale ou sonore, des surfaces à retour haptique, des actionneurs. Les fichiers informatiques mémorisés peuvent être des fichiers à destination des objets multimédia. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés sur lesquels : - la figure 1 illustre un exemple d'un scénario interactif - la figure 2 illustre un exemple d'un scénario interactif avec une structure HTSPN, - la figure 3 illustre l'utilisation d'intervalles fixes et interactifs, - la figure 4 illustre un modèle de réseau de pétri coloré (CPN) à intervalle fixe, - la figure 5 illustre un modèle CPN à intervalle flexible, - la figure 6 illustre un modèle CPN pour le traitement d'un point d'interaction, - la figure 7 illustre un modèle CPN à intervalle interactif - la figure 8 illustre un modèle CPN d'une boite fixe, - la figure 9 illustre un modèle CPN avec un point d'interaction de début de boite, - la figure 10 illustre un modèle CPN avec un point d'interaction de fin de boite, - la figure 11 illustre un modèle CPN avec des points d'interaction de début et de fin de boite, - la figure 12 illustre l'utilisation de boites hiérarchiques, - la figure 13 illustre un exemple de scenario interactif avec des relations fixes et flexibles, - la figure 14 illustre une time-line d'une exécution d'un scénario interactif avec des relations fixes et flexibles, - la figure 15 illustre un modèle CPN pour la synchronisation d'intervalles fixes, - la figure 16 illustre une time-line d'une exécution d'un scénario interactif avec des relations fixes et flexibles comprenant des points d'interaction déclenchés, - la figure 17 illustre un modèle CPN pour la synchronisation d'intervalles interactifs, - la figure 18a et 18b illustrent une transformation d'un scenario interactif avec des relations fixes et flexibles dans le modèle HTSPN, - la figure 19 illustre un rapport de simulation correspondant à l'exécution d'un scénario interactif avec des relations fixes et flexibles, - la figure 20 illustre un rapport de simulation correspondant à l'exécution d'un scénario interactif avec des relations fixes et flexibles comprenant des points d'interaction déclenchés, - la figure 21 illustre un modèle CPN de lecture d'un fichier, - la figure 22 illustre un modèle CPN d'adjonction de fichiers, - la figure 23 illustre un modèle CPN d'inversion d'un fichier, - la figure 24 illustre la lecture et le traitement de deux fichiers, - la figure 25 illustre une time-line d'une lecture et d'un traitement de deux fichiers, - les figures 26a, 26b, et 26c illustrent un exemple de réalisation avec CPN Tools d'une lecture et d'un traitement de deux fichiers, et - la figure 27 illustre un rapport de simulation d'une lecture et d'un traitement de deux fichiers. La description suivante comprend un modèle de calcul basé sur des réseaux de Petri colorés (acronyme anglais CPN pour « Colored Petri Nets ») pour réaliser des scénarios multimédias interactifs. Nous avons modélisé les processus et les relations temporelles au moyen de réseaux de Pétri avec le logiciel CPN pour garder la compatibilité avec le modèle d'i-score. En modélisant les flux au moyen d'un jeton par trame, nous avons simulé les compositions fonctionnelles synchrones et asynchrones et nous avons testé leur bon fonctionnement. Actuellement, la création de systèmes interactifs multimédias basés sur des scénarios écrits est un défi qui requiert de pouvoir gérer des évènements dynamiques et statiques et également des données dynamiques et statiques. Les partitions interactives proposent un outil pour écrire et exécuter des scénarios interactifs composés de plusieurs processus multimédias. Ce modèle permet de contrôler en temps réel des évènements dynamiques et statiques maintenant l'organisation temporelle du scénario pendant son écriture et son exécution. I-score est un logiciel qui permet de créer et d'exécuter des scénarios interactifs et multimédias. La modélisation du logiciel est basée sur les Réseaux de Petri hiérachiques à flux temporisés (HTSPN). Les places et les transitions du réseau de Petri modélisent les aspects temporels du scenario (c'est-à-dire qu'elles définissent un ordre partiel entre les événements statiques et dynamiques) définis au moment de la composition. Cet article présente un développement d'I-score ayant pour but de gérer des données complexes, en particulier, des flux de données dynamiques et statiques ; et des évènements dynamiques et statiques. Les développements du logiciel ajoutent la possibilité d'écrire des programmes comportant des compositions de processus destinés à s'exécuter avec des entrées/sorties multimédia. Notre idée est d'utiliser les réseaux de Petri colorés (CPNs) pour modéliser les données complexes et les aspects dynamiques des compositions fonctionnelles des processus. Les flux multimédias sont toujours découpés en trames temporelles pour être transportés d'un processus à un autre. Puis, selon notre approche, nous représentons ces trames par des jetons colorés qui sont gérés par les processus. Notre approche propose la notion de composition fonctionnelle asynchrone. Cela correspond au cas où les processus ne s'exécutent pas en même temps. Cela nécessite de retenir le flux de données de sortie du processus dans une mémoire-tampon (buffer) jusqu'à ce que les données soient exécutées par un autre processus. Dans le contexte des partitions interactives, le moment où les données retenues seront lues n'est ni connu au moment de l'écriture ni au moment de l'exécution du scénario. Cependant, la durée des mémoires tampon est limitée à la durée du scénario et à sa fin. Nous souhaitons vérifier ce type de propriétés à travers le concept de CPNs. Dans une deuxième partie, nous présentons le logiciel i-score et le concept de Réseaux de Petri Colorés (CPNs). Dans une troisième partie, nous développons notre modèle pour exécuter des calculs interactifs grâce aux CPNs. Dans une quatrième partie, nous développons notre modèle pour gérer des données complexes. Pour finir, nous présentons notre conclusion dans une cinquième partie. I-score est un logiciel pour l'écriture et l'exécution de scénarios interactifs et multimédias. Le logiciel a deux fonctionnalités : l'écriture d'une part, et l'interprétation (lecture). La fonction d'écriture permet à l'artiste de créer un scénario. La fonction d'interprétation permet d'exécuter le scénario en temps-réel avec de l' interactivité. La fonction d'écriture permet de créer un scénario comprenant une série d'objets multimédias représentés par des boîtes sur une page sur laquelle l'abscisse correspond à la time-line et l'ordonnée ne représente pas de données. Les boîtes ont une temporalité avec un début, une durée et un processus multimédia. Dans I-score, l'exécution des processus multimédias est apportée par des logiciels externes comme MAX/MSP ou PURE DATA, et utilise des protocoles multimédias tels qu'OSC pour leur envoyer des valeurs/paramètres. Le séquenceur peut utiliser des boîtes hiérarchisées regroupant plusieurs boîtes ayant leur propre organisation temporelle. Ces boîtes hiérarchisées rendent plus aisée la création de scénarios longs. Le séquenceur définit partiellement l'organisation temporelle des scénarios en utilisant le principe d'Allen pour les relations temporelles entre les boîtes. Ce principe régit la priorité temporelle entre les boîtes, en complément des mesures. Ceux-ci représentent les antécédents temporels entre les boites, et sont complétés par des mesures quantitatives sous la forme de durées. Il est possible de programmer le départ d'une boîte indépendamment de la fin d'une autre boîte en déterminant une durée. I-score permet aux auteurs de construire un scénario interactif en ajoutant des évènements interactifs discrets qui sont déclenchés pendant l'exécution et modifiés soit au début soit durant l'exécution d'une boîte. Les relations temporelles sont préservées que ce soit pendant la création ou pendant l'exécution. C'est pourquoi, un scénario a un nombre limité de possibilités d'interprétation. Dans le Figure 1, nous montrons l'exemple d'un scénario interactif où la boîte A a un début et une durée fixés, la boîte C a un point d'interaction à son début, puis le moment du début peut être modifié durant l'exécution, la boîte D a un point d'interaction à sa fin, puis la durée de la boîte peut être modifiée durant l'exécution, et la boîte B mélange les comportements des deux boîtes précédemment citées. Il est à noter que les relations temporelles entre les boîtes B et C sont représentées par des pointillés, car la durée des relations temporelles n'est pas déterminée mais se situe dans une fourchette de valeurs. Les flèches représentées en trait plein ont une durée déterminée. I-score est capable de traduire un scénario dans une structure HTSPN pour son exécution. Cette traduction permet de déclencher des évènements interactifs ainsi que de maintenir des relations temporelles durant l'exécution du scénario. La méthode de traduction des scénarios en un langage (structure) HTSPN est la suivante : - Transformer en transition chaque point de contrôle (par ex, au début et à la fin de chaque boite, - Fusionner les transitions qui représentent des points de contrôle qui sont exécutés au même instant, - Ajouter un arc de séquence/une place/un arc entre deux transitions qui ont une durée temporelle. Ajouter un intervalle de temps sur les arcs avec une gamme de valeurs de durées de la relation, - La condition de croisement des transitions qui représente les points d'interaction est conditionnée par la réception d'un message extérieur. La transition est lancée automatiquement si l'évènement extérieur n'est pas déclenché dans l'intervalle de temps de la relation temporelle. La Figure 2 montre la transformation du scenario de la Figure 1 en une structure HTSPN. Les réseaux de Petri Colorés sont un langage graphique qui permet de modéliser et de contrôler les systèmes concurrents et distribués. C'est la combinaison d'un modèle de Réseaux de Petri bien défini avec le langage de programmation de haut-niveau Standard ML. Les modèles générés par CPN peuvent être simulés. Cela permet d'explorer les comportements possibles du système. Les CPN sont basés sur un mécanisme de structuration hiérarchique qui permet de structurer un modèle dans un ensemble de modules. Cela permet de modéliser des systèmes complexes de manière plus aisée. Les CPNs permettent d'exprimer une notion de temps. Le contrôle des modèles CPN est automatique et est supporté par une méthode espace-état. Typiquement, cette méthode calcule tous les états atteints et les changements d'état du modèle CPN et les représente directement sous forme de graphique où les noeuds représentent des états et les arcs représentent des évènements à venir. Depuis l'espace-état, il est possible de vérifier certaines propriétés du système comme l'absence de blocage. La définition des Réseaux de Petri colorés est la suivante. Un réseau de Petri coloré non-hiérarchique synchrone est un n-uplet à 9 valeurs CPNT = (P,T,A,E,V,C,G,E,I) Avec : P un ensemble fini de lieux T un ensemble fini de transitions tel que P n T = 0 A un ensemble d'arcs tel que AcP x T v T x P E est un ensemble fini non vide d'ensemble colorés. Chaque ensemble coloré est temporisé ou non. V est un ensemble fini de variables typées tel que Type[v] E E pour toutes les variables v E V, C : P S est une fonction d'ensemble coloré qui assigne un ensemble de couleur à chaque lieu. Un lieu p est temporisé si C(p) est temporisé, sinon p n'est pas temporisé, G : T EXPRv est une fonction de garde qui assigne une garde à chaque transition t de sorte que Type[G(t)]=Bool E : A -p EXPRv est une fonction d'expression d'arc qui assigne une expression d'arc à chaque arc a de sorte que Type[E(a)] = C(p)Ms si p n'est pas temporisé, ou Type[E(a)] = C(p)TMS si p est temporisé. Ici, p est le lieu connecté à l'arc a. I :P- EXPR0 est une fonction d'initialisation qui assigne une expression d'initialisation à chaque lieu p de sorte que Type[I(p)] = C(p)ms si p n'est pas n'est pas temporisé , ou Type[I(p)] = C(p)TMS si p est temporisé. CPN TOOLS est un outil pour l'édition, la simulation et l'analyse des modèles CPNs. Cet outil supporte des modèles CPN hiérarchiques temporisés ou non temporisés. L'utilisateur de CPN TOOLS travaille directement sur une représentation graphique du modèle CPN. Nous pouvons construire les modules de modèles CPN. Ceci est très utile pour construire de grands scénarios. La simulation peut être effectuée étape par étape ou on peut sélectionner une des étapes de la simulation qui doit être exécutée. Nous pouvons aussi définir des critères d'arrêt et des points de contrôle. Nous pouvons également générer des espaces-états complets et les utiliser comme moyens pour vérifier les modèles. CPN TOOLS utilise des méthodes efficaces pour atténuer les problèmes d'explosion d'état. Cet outil permet également la vérification des modèles. Nous pouvons également collecter des données des états du réseau pendant la simulation et créer des rapports sophistiqués. CPN TOOLS contient également une large bibliothèque destinée à diverses utilisations. Comme nous l'avons expliqué auparavant, les artistes peuvent créer dans I-score un scénario définissant une organisation temporelle partielle d'éléments multimédias, représentés par des boîtes, en utilisant des relations temporelles. De plus, les auteurs peuvent ajouter des points d'interaction pour modifier soit la date de début soit la durée des boîtes au cours de l'exécution. Les relations temporelles doivent se maintenir durant le temps de l'édition et l'exécution. De plus, I-score permet de grouper des boîtes dans une boîte hiérarchique. Ceci est très important pour pouvoir créer de grands scénarios. Dans notre approche, nous développons un modèle CPN pour chaque structure qui définit un scénario interactif (relations temporelles, boîtes et points d'interaction). Cela permet de construire un modèle modulable et paramétrable qui peut être réutilisé et étendu. Dans les paragraphes suivants, nous présenterons les modules CPNs implémentés et une simulation dans CPN TOOLS. Selon notre approche, tous les éléments d'un scénario sont modélisés comme des intervalles. Nous définissons deux types d'intervalles : intervalles fixes et intervalles interactifs (Figure 3). Les intervalles fixes ont des relations temporelles avec des durées déterminées, alors que les intervalles interactifs ont une fourchette de valeurs définie par une durée minimum et une durée maximum. De plus, les intervalles interactifs ont un point d'interaction qui arrête l'intervalle s'il est déclenché entre la durée de l'intervalle. Un intervalle fixe consiste à appliquer un délai entre deux points. Ce délai peut être implémenté dans CPN en utilisant l'expression de délais @+duration dans l'inscription d'un arc de production d'une transition (Figure 4). Un intervalle interactif applique un délai entre deux points dont la durée est flexible (il a une durée minimum et une durée maximum). L'intervalle s'arrête lorsqu'il atteint la durée maximum ou le point d'interaction est déclenché lorsque la durée minimum est écoulée. Donc, nous analysons l'intervalle interactif dans un module afin de modéliser la durée flexible et d'autre part pour manipuler le point d'interaction. On utilise deux intervalles fixes pour modéliser des intervalles flexibles (Figure 5). Le premier intervalle attend la durée minimum de l'intervalle flexible, et le second attend le temps restant de la durée maximum. Nous manipulons un point d'interaction en utilisant un réseau qui accepte un évènement s'il est déclenché après que le module ait commencé et avant que le signal se soit arrêté. Nous ignorons les évènements qui ne sont pas acceptés, et le réseau termine un évènement commencé ou un signal d'arrêt. Maintenant, nous utilisons les deux modules précédemment cités pour modéliser les intervalles interactifs (Figure 7). Puis, nous mettons en route le module pour commencer à manipuler les points d'interaction quand la durée minimale est écoulée et nous l'arrêtons quand l'intervalle flexible atteint la durée maximale. Nous limitons le nombre de fois où le module peut être (est capable) arrêté lorsqu'il y a plusieurs intervalles qui partagent le même point d'interaction. Cela sera décrit plus en détail dans la partie de la description relative à la synchronisation. Dans I-score, les éléments multimédias ont des structures temporelles représentées par des boîtes. Une boîte a une durée et une date de début qui peut être modifiée durant le temps d'exécution en ajoutant des points d'interaction. Les propriétés temporelles du scénario doivent être maintenues durant le temps d'édition et d'exécution. Selon notre approche, nous modélisons les boîtes en intervalles fixe ou interactif auxquelles on attache un processus. Nos modèles des différents types de boîtes sont décrits ci-dessous. Une boîte fixe est modélisée comme un intervalle fixe avec une durée. De plus, le processus attaché à la boîte commence et se termine avec l'intervalle (Figure 8). Un point d'interaction au début de la boîte permet de prévoir ou de retarder le début de la boîte pendant l'exécution. Dans I-score, les compositeurs définissent un intervalle de temps durant lequel un évènement peut être déclenché. Alors, la boîte commencera si l'évènement est déclenché pendant l'intervalle ou le temps maximum est écoulé. Dans notre approche, nous modélisons cette boîte en ajoutant un intervalle interactif au début d'une boîte fixe (Figure 9). L'intervalle interactif a le point d'interaction de la boîte et il contrôle le début de la boîte. Par ailleurs, la durée de la boîte peut être modifiée durant l'exécution s'il y a un point d'interaction à la fin de la boîte. Les compositeurs définissent un intervalle de temps dans lequel un évènement particulier peut être déclenché. Alors, la boîte finira si l'évènement est déclenché durant l'intervalle ou si la boîte atteint sa durée maximale. Nous modélisons cette boîte en remplaçant l'intervalle fixe de la boîte fixe (Figure 8) par un intervalle interactif (Figure 10). L'intervalle interactif manipule le point d'interaction de la boîte et il contraint la durée de la durée de la boîte. Point d'interaction au début et à la fin de la boîte : dans I-score, les compositeurs peuvent combiner les deux comportements décrits ci-dessus afin de disposer d'un point d'interaction au début et à la fin de la boîte. Nous profitons de la modularité de notre approche pour former cette boîte. Nous ajoutons un intervalle interactif avant le début de la boîte avec un point d'interaction à la fin (Figure 11). La hiérarchie est très importante pour construire de grands scénarios. I-score permet cette fonction en permettant de grouper des boîtes dans une boîte hiérarchique. En effet, une boîte hiérarchique représente un scénario entier qui contient toutes les boîtes, les boîtes hiérarchiques, les relations temporelles et les points d'interaction. Dans notre approche, la boîte hiérarchique consiste en deux transitions afin de synchroniser le début et la fin des boîtes dépendantes. Aussi, sa durée dépend de l'organisation temporelle du sous-scénario. Nous illustrons nos propos dans la Figure 12. Des relations temporelles définissent le début des boîtes. Donc une boîte commence quand toutes ses précédentes sont accomplies. Dans I-score, toutes les relations précédant une boîte sont flexibles si la boîte a un point d'interaction au début. Sinon, elles sont fixes (Figure 13). En suivant, nous allons présenter une opération de fusion pour réduire plusieurs relations du même type à un intervalle équivalent. Ceci permet de créer un mécanisme générique pour maintenir les relations temporelles dans notre modèle Dans le cas d'une fusion d'intervalles fixes, les relations fixes précédant une boîte doivent être accomplies. Puis, la boîte va commencer quand tous les intervalles fixes sont terminés. Nous illustrons ce comportement dans la Figure 14 qui est une time-line d'une exécution du scénario montré dans la Figure 13. On peut observer que la boîte D débute quand le dernier de ces précédents intervalles fixes se termine (intervalle ABD). Dans notre modèle, nous fusionnons plusieurs intervalles fixes en synchronisant leurs fins avec une transition (Figure 15). Alors, une boîte commencera quand toutes ses relations précédentes ont fini. Dans le cas d'une fusion d'intervalles interactifs, les relations temporelles précédant une boîte avec un point d'interaction sont flexibles (c'est-à-dire, qu'elles ont un minimum et une durée maximale). Dans ce cas, la boîte commencera quand une de ses relations précédentes aura atteint sa durée maximale ou que l'événement attaché à la boîte se déclenche après que toutes ses relations aient atteint leur durée minimum. Nous illustrons ce comportement dans la Figure 16 qui montre l'exécution du scénario montré dans la Figure 13. Ici, le déclenchement d'un événement est représenté par un "x". Notez que l'intervalle merge(AC; BC) est un nouvel intervalle de temps dans lequel la boîte C démarre. Cet intervalle est défini par la durée minimum de l'intervalle ABC et par la durée maximale de l'intervalle AAC. Alors, la boîte C commencera quand ce nouvel intervalle atteint sa durée ou que l'événement attaché à la boîte est déclenché pendant l'intervalle. Dans notre approche, nous utilisons des intervalles interactifs pour modéliser des relations temporelles précédant une boîte ayant un point d'interaction. Nous fusionnons plusieurs intervalles interactifs en synchronisant la fin de leurs durées minimales avec le début d'un module afin de manipuler le point d'interaction. De plus, nous relions la fin de leurs durées maximales avec l'arrêt du module (Figure 17). Donc, la boîte commencera quand un intervalle atteindra sa durée maximale ou que l'événement attaché à la boîte est déclenché après que toutes ses relations précédentes aient atteint leur durée minimale. Nous limitons le nombre de temps où l'intervalle est stoppé en utilisant la place « activé » (« enable » en langue anglaise). Nous présentons maintenant la simulation du scénario montré dans la Figure 13. Nous mettons en oeuvre et simulons notre modèle dans CPN TOOLS. Nous produisons également un rapport avec les états de la simulation. Ce rapport permet de débuguer le comportement de notre modèle et de vérifier si son exécution est correcte. Dans les Figures 18a et 18b, nous démontrons la transformation du scénario de la Figure 13 dans notre modèle. Tout d'abord, nous simulons le scénario en laissant tous les intervalles interactifs atteindre leur durée maximum. Puis, nous comparons le rapport de simulation (Figure 19) avec la time-line montrée dans la Figure 14 et nous observons que notre modèle est exécuté correctement. Alors, nous simulons le scénario déclenchant tous les points d'interaction. Nous comparons le rapport de simulation (Figure 20) avec la time-line de la Figure 16 et nous observons que notre modèle s'est exécuté correctement. Dans cette partie, nous présentons une extension du modèle pour manipuler les données complexes décrites plus haut. Nous représentons les flux audio par des jetons colorés de CPNs. Dans notre approche, un flux audio consiste en un ensemble de jetons dont la couleur a une valeur (i, d) dans lequel i est l'indice de la trame audio et où d est sa valeur correspondante. La durée entre chaque trame audio doit être maintenue. Dans le paragraphe suivant, nous décrivons des modules CPN pour du traitement basique de fichiers audio. D'abord, nous présentons un modèle CPN pour lire des fichiers audio. Puis, nous montrerons que nous pouvons ajouter et inverser des fichiers en réutilisant le module précédent. Finalement, nous montrerons la mise en oeuvre et la simulation d'un scénario dans CPN TOOLS. Dans notre approche, la lecture de fichiers audio consiste dans l'acquisition de trames audio avec un intervalle spécifique de temps (ex. durée entre les trames). Nous modélisons le précédent comportement obtenant ainsi une trame audio (c'est-à-dire, un jeton coloré) de chaque intervalle de temps (Figure 21). Le module continuera à lire les trames jusqu'à ce qu'il atteigne la fin du fichier (acronyme anglais EOF pour « end of file ») ou jusqu'à ce qu'il y ait un signal de fin. Les sorties de notre module sont la lecture des trames et le nombre de trames lues. De plus, il indique également si le module a atteint la fin du fichier, et l'instant auquel l'intervalle de temps entre les trames est écoulé. La dernière caractéristique est utile si on veut synchroniser la production des deux fichiers. Nous ajoutons deux fichiers en concaténant leurs productions. Nous avons profité de la modularité de notre modèle pour construire ce module à partir du précédent (Figure 22). Le module lit le premier fichier puis synchronise le début de la lecture du second fichier. Cela signifie que la première trame du second fichier sera lue quand la durée entre les deux trames du premier fichier sera écoulée. De plus, nous ajoutons un offset aux indices du deuxième fichier pour construire correctement le dossier concaténé. Ce module se terminera si les deux fichiers sont correctement ajoutés ou s'il y a un signal de fin. Puis, les productions de ce modèle sont le fichier ajouté et le nombre de trames concaténés. Dans notre approche, le module inverse le fichier (c'est-à-dire, il inverse l'ordre du fichier) à un moment donné puis il lit le fichier inversé. Donc, nous lisons le fichier une fois (la durée entre les trames est égale à zéro) et nous renversons l'ordre de ses indices. Une fois que le fichier entier est inversé, on utilise le module de lecture du fichier pour lire le fichier inversé pendant la durée entre les trames (Figure 23). Ce module produit la même chose que le module pour la lecture des fichiers. Dans ce paragraphe, nous allons illustrer l'utilisation des modules précédemment décrits. La Figure 24 montre un scénario où deux fichiers sont traités. Tout d'abord, les deux fichiers sont lus, mais la lecture du premier fichier peut être arrêtée par le déclenchement d'un point d'interaction. Alors, le module pour inverser les fichiers reçoit, comme entrée, les trames du second fichier pour l'inverser. Finalement, le module pour ajouter des fichiers reçoit, comme entrée, le second fichier inversé et le premier fichier pour les concaténer. Il est à noter que le point d'interaction de cette boîte est différent. Cette représentation signifie que le point d'interaction a deux évènements attachés : l'évènement déclenché par le performeur et l'évènement déclenché par le processus quand il est terminé. Nous montrons l'exécution de ce scénario dans la Figure 25. Dans notre approche, nous organisons notre traitement des données du module en utilisant les boîtes décrites plus haut. Pour simplifier, nous lions les ensemble les boîtes et les modules de traitement. De plus, les boîtes ont des entrées et des sorties, et les intervalles permettent de communiquer les valeurs entre les boîtes. Ces valeurs peuvent être utilisées comme des paramètres pour les processus. Par exemple, dans la Figure 24 le module d'inversion des fichiers reçoit comme entrée, la sortie du module de lecture des fichiers par l'intervalle ABD. De plus, la durée des boîtes peut être contrainte par la durée de son processus. Nous modélisons cette fonction additionnelle en ajoutant un point d'interaction à la fin de la boîte dont l'évènement associé est déclenché quand le processus se termine. Nous implémentons et simulons cet exemple dans CPN TOOLS (Figures 26a, 26bet 26c). Nous comparons le rapport de simulation (Figure 27) avec la time-line montrée en Figure 25 et on observe que notre modèle est exécuté correctement. Il est à noter que nous avons arrêté le module pour lire le premier fichier au temps 7 en déclenchant son point d'interaction, et le module pour ajouter un fichier a été arrêté au temps 53 quand le processus s'est terminé. Ci-dessus, nous avons présenté un modèle pour exécuter des scénarios interactifs avec la capacité de gérer des données complexes, en particulier, des données de flux audio. Nous avons utilisé les Réseaux de Petri Colorés (CPNs) pour modéliser les trames audio comme des jetons colorés qui sont gérés par les processus. Ces processus ont des entrées et des sorties, et ils peuvent se transmettre des valeurs entre eux à travers les intervalles. Cela permet la composition fonctionnelle des processus. Nous avons tiré parti de cette composition fonctionnelle et de la hiérarchisation apportée par les CPNs pour construire un modèle modulaire. Ainsi, nous avons développé le modèle du logiciel I-score avec des modules de traitement des fichiers audio comme les modules de lecture, d'adjonction et d'inversion de fichiers. Nous avons illustré la notion de composition fonctionnelle asynchrone de notre modèle en simulant le scénario montré dans la Figure 24. Ici, les sorties des modules d'inversion et d'adjonction sont mis en mémoire tampon avant que le module d'adjonction des fichiers commence. Aussi, nous avons implémenté une méthode pour fusionner des intervalles qui permettent de traduire n'importe quelle propriété temporelle définie par l'utilisateur dans notre modèle. Nous avons mis en oeuvre notre modèle dans CPN TOOLS et ensuite nous avons simulé trois scénarios qui ont permis d'observer que notre approche modélise correctement des scénarios interactifs et des flux audio.10 REVENDICATIONS1. Procédé de détermination d'au moins un signal de commande à destination d'au moins un objet multimédia en fonction d'au moins un signal d' entrée provenant de capteurs ou de mémoires informatiques comprenant au moins un fichier informatique, caractérisé par le fait qu'il comprend l'étape suivante : On détermine au moins un signal de commande en fonction d'au moins un signal d'entrée et d'au moins une loi de commande mémorisée basée sur des réseaux de pétri hiérarchiques à flux temporisés, une loi de commande comprenant au moins une relation entre au moins deux signaux parmi les signaux d'entrée et les signaux de commande. 2. Procédé selon la revendication 1, dans lequel les relations sont exécutées en fonction de leur hiérarchie. 3. Procédé selon l'une quelconque des revendications précédentes, dans lequel une relation est apte à réaliser des opérations de traitement du signal sur au moins un signal d'entrée et/ou au moins un signal de sortie. 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel une relation est apte à combiner au moins deux signaux parmi les signaux d'entrée et les signaux de commande, afin de déterminer au moins un signal de commande. 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel une relation est apte à extraire au moins un attribut d'au moins un signal pour l'appliquer à au moins un autre signal, un attribut étant choisi parmi l'amplitude, la fréquence et la forme d'un signal. 6. Procédé selon l'une quelconque des revendications précédentes dans lequel, une relation comprend une durée pendant laquelle la relation est réalisée. 7. Procédé selon la revendication 6, dans lequel, la durée d'une relation est modifiée en fonction de conditions dépendant d'au moins un signal d'entrée et/ou de commande. 8. Procédé selon l'une quelconque des revendications précédentes dans lequel, une loi de commande comprend une durée de temporisation entre l'exécution d'une relation et l'exécution d'au moins une autre relation. 9. Procédé selon la revendication 8, dans lequel, la durée de temporisation est modifiée en fonction de conditions dépendant d'au moins un signal d'entrée et/ou de commande. 10. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'unité de temps d'une loi de commande est égale à une trame. 11. Procédé selon l'une quelconque des revendications précédentes, dans lequel une loi de commande comprend au moins un signal de commande mémorisé émis en fonction d'une référence temporelle absolue. 12. Procédé selon l'une quelconque des revendications précédentes, dans lequel les capteurs sont des capteurs de lumière, des dispositifs d'acquisition de vidéo, des capteurs de son, des dispositifs d'acquisition sonore, des capteurs de toucher, des capteurs de mouvement. 13. Procédé selon l'une quelconque des revendications précédentes, dans lequel les objets multimédia sont des émetteurs de lumière, des dispositifs d'affichage ou de projection vidéo, des émetteurs de son, des dispositifs de diffusion musicale ou sonore, des surfaces à retour haptique, des actionneurs. 14. Procédé selon la revendication 13, dans lequel les fichiers informatiques mémorisés sont des fichiers à destination des objets multimédia.