ABSTRAIT
Dans cet article, nous présentons de nouvelles opportunités pour surmonter certaines des limitations inhérentes à un environnement de flux de données visuel tel que Max / MSP / Jitter, en utilisant des extensions spécifiques au domaine (audio et graphique) du langage de programmation Lua en tant que bibliothèques (externes) . Lua est flexible, extensible et efficace, ce qui en fait un choix idéal pour concevoir une interface programmatique pour la composition multimédia.
Mots clés
Lua, Max / MSP, Jitter, ordonnancement, microsound, OpenGL, composition, programmation fonctionnelle.
1. INTRODUCTION
L'artiste numérique contemporain peut choisir parmi de nombreux outils logiciels pour exprimer son idée. La famille d'applications Max (Max / MSP / Jitte, PureData, etc.) sont des choix populaires pour la composition d'œuvres multimédias interactives numériques en raison de l'interface graphique accessible, de nombreuses liaisons aux processus et protocoles multimédias et d'une philosophie ouverte. La famille Max implémente une architecture visuelle de flux de données via une interface de correction avec à la fois un flux d'événements et un flux de flux. Bien que ce type d'interface soit puissant et flexible, l'environnement Max / MSP / Jitter comporte également certaines limitations inhérentes (tableau 1). Poussés par des objectifs artistiques, les auteurs souhaitaient une interface dynamique pour surmonter ces problèmes, prenant en charge à la fois le traitement de données de bas niveau et le contrôle de haut niveau. Comme le note Puckette, une solution idéale consiste à intégrer un langage interprété:
"Plutôt qu'un environnement de programmation, Max est fondamentalement un système pour planifier des tâches en temps réel et gérer la communication entre elles. La programmation en tant que telle est mieux entreprise au sein des tâches que par la construction de réseaux de tâches existantes. Cela peut être fait en écrivant des '' externes '' en C, ou en important des interprètes entiers ... "
Tableau 1. Contraintes inhérentes à l'environnement de flux de données visuel Max
Focus sur la représentation visuelle de l'interconnexion des processus
Entrave les structures de données expressives
Graphiques dynamiques et structures de données problématiques
Un grand nombre de processeurs peu maniables
Flux de contrôle procédural difficile Portée variable minimale
La plupart des nœuds de
processeur sont des boîtes noires
Limite la granularité du contrôle des processus
L'écriture de processeurs nécessite un développement C hors ligne
Quantification du taux de bloc des commandes audio
Planificateur et sémantique séparés pour le contrôle et l'audio
Granularité et événements précis pour l'échantillon uniquement dans la boîte noire
Il existe de nombreuses extensions (externes) pour Max qui intègrent des langages interprétés, qu'il s'agisse de langages génériques (Javascript dans js [29], LISP dans maxlisp [5], Python dans py / pyext [8]) ou de langages spécifiques à un domaine (comme csound ~ [23] et rtcmix ~ [6] pour les liaisons audio DSP et Ruby pour les graphiques GridFlow de PD [3]). Chacun aborde des problèmes particuliers de
composition multimédia, mais aucun ne prend en charge à la fois l'audio et les graphiques tout en satisfaisant les exigences de performance en temps réel des auteurs.
Les auteurs ont donc choisi d'intégrer le langage de script Lua [12] dans l'environnement Max. Les auteurs de Lua décrivent Lua comme un langage d'extension extensible [11] spécialement conçu pour être intégré dans des programmes hôtes et étendu par des API spécifiques au domaine. Lua est un langage de script efficace basé sur des tables associatives et des capacités de programmation fonctionnelle [1], des coroutines et des méta-mécanismes pour construire des structures de programmation de niveau supérieur. Pour un langage interprété, Lua se débrouille extrêmement bien en termes de vitesse et d'utilisation de la mémoire [1]. Il est fréquemment utilisé pour la programmation de la logique de jeu (par exemple World of Warcraft [25]) et l'extension d'application (par exemple Adobe Lightroom [13]).
Les extensions lua ~ et jit.gl.lua de Max présentées dans cet article facilitent le comportement dynamique arbitrairement complexe pour les graphiques audio DSP et OpenGL respectivement tout en s'interfaçant avec l'interface graphique et les bibliothèques pratiques de Max / MSP / Jitter. Les décisions prises dans la conception de lua ~ et jit.gl.lua varient en fonction des exigences du domaine d'application, mais visent toutes deux à équilibrer la flexibilité et l'efficacité avec une minimisation des idées préconçues sur l'utilisation potentielle.
2. LUA
~ Le lua ~ external intègre des extensions spécifiques au domaine de la langue Lua pour l'audio numérique. Étonnamment, il n’existe que peu d’extensions de ce type (notamment le projet de recherche Geiger ALUA [7] et les récentes liaisons de haut niveau pour l’API CSound) et aucune qui offre un degré de contrôle élevé pour satisfaire les besoins des auteurs. Suivant la philosophie de Lua, les
extensions du domaine audio en lua ~ ont été conçues pour fournir des méta mécanismes pour la composition musicale numérique plutôt qu'une variété de structures musicales préconçues (comme approprié pour un domaine si lourd de complexité et d'ambiguïté [4]). Les compositions de musique informatique peuvent impliquer des processus et des structures en série et parallèles dans un réseau complexe de relations, produisant éventuellement des échantillons d'audio numérique. Surtout, ces processus et structures sont dynamiques et éventuellement activement déterminés dans le temps. Le lua ~ external étend donc les excellentes capacités de description de données et de programmation fonctionnelle de Lua pour le domaine audio numérique dans deux domaines principaux, tous deux évalués sous le contrôle d'un ordonnanceur précis.
• Contrôle fonctionnel simultané (via coroutines)
• Traitement du signal (via des graphes de générateur d'unité)
Un objet lua ~ intégré dans un patch Max peut charger et interpréter des scripts Lua qui utilisent ces capacités étendues afin de recevoir, transformer et produire des signaux MSP et des messages Max en conséquence. Un exemple de code d'un script typique est donné à la figure 1.
2.1. Contrôle fonctionnel simultané
Le contrôle fonctionnel simultané est basé sur une extension des coroutines Lua. Une coroutine représente un fil d'exécution indépendant pour une planification déterministe (également connue sous le nom de multitâche collaboratif). Dans lua ~, ces coroutines sont étendues pour connaître l'horloge d'échantillonnage, avec un petit nombre de fonctions supplémentaires pour interagir avec le planificateur. L'ordonnancement du flux de contrôle à l'aide de coroutines dans lua ~ est une variation du modèle de conception de l'activation basée sur la continuation [13].
Les coroutines sont lancées avec la fonction go (), qui prend un temps de retard comme premier argument et une fonction comme second argument 1. En fait, une copie de cette fonction est insérée dans la liste des activités parallèles du planificateur, pour être activée une fois le délai écoulé. Toutes les instructions d'une coroutine se produisent instantanément par rapport à l'horloge d'échantillonnage, à l'exception de wait () et play (). L'appel wait (dur) donnera l'exécution du corps de la fonction pendant des secondes, pendant lesquelles d'autres coroutines peuvent s'exécuter ou le traitement du signal se produire, et l'appel now () renvoie le nombre de secondes depuis le lancement de la coroutine. Toutes les spécifications de temps sont précises.
2.2. Traitement de signal
Étant donné que l'API SDK Max / MSP ne permet pas l'instanciation dynamique d'un objet MSP, un ensemble différent de générateurs d'unités de traitement du signal a été fourni, basé sur la bibliothèque C ++ efficace Synz [22]. Un SDK pour étendre le vocabulaire DSP est prévu comme travail futur. Les primitives de traitement du signal (générateurs d'unités) sont créées en appelant des fonctions de constructeur de bibliothèque, telles que Sine (), Env (), Biquad () etc. Sine (Sine (0,1) * 400 + 500) créera un graphique de synthèse FM de base modulant entre 100 et 900 Hz dix fois par seconde. Notez que les opérateurs de base (+, *, -, /,%, ^) sont surchargés pour les générateurs d'unité pour faciliter la lisibilité. L'appel de jeu (bus, dur, unité) ajoute l'unité génératrice d'unité comme entrée au bus pendant une durée de secondes secondes (ce qui donne la coroutine entre les deux). Ce bus peut être le bus Out global, qui représente les sorties lua ~ dans Max / MSP, ou un autre bus créé par le programmeur à l'aide de Bus ().
Figure 1. Échantillon de code superposant plusieurs trains d'impulsions avec un
contrôle algorithmique distinct de la durée et de la largeur d'impulsion dans chaque train.
2.3. Éviter le taux de blocage
L'algorithme de l'ordonnanceur au cœur de la lua ~ external gère les coroutines et les graphes de traitement du signal, en évitant les limitations de contrôle du taux de bloc. Le planificateur évalue paresseusement les sections de graphique
uniquement lorsque cela est nécessaire de manière déterministe, maximisant le potentiel de traitement vectoriel lorsque cela est possible. La latence entre les entrées et les sorties n'est encourue que pour les sections de graphique avec des cycles (rétroaction) et peut être réduite à des taux de contrôle arbitraires. Lua ~ permet ainsi un échantillon d'articulation précise de la composition qui peut être dynamiquement déterministe. Les changements d'état qui impliquent un code interprété pour générer de nouveaux graphiques de signaux peuvent se produire à des taux inférieurs à la milliseconde, idéal pour les microsons génératifs [24].
2.4. Graphiques dynamiques et multiplicité
Dans l'interface visuelle Max, le graphique audio ne peut pas être recompilé sans discontinuités audibles, limitant le traitement audio dynamique à des structures statiques pré-allouées. De même, le nombre maximal de voix parallèles doit également être préalloué (par exemple, les arguments poly ~). En revanche, lua ~ prend en charge des graphiques de signaux dynamiques génératifs sans discontinuités.
2.5. Optimisation pour le traitement en temps réel
La majorité du code de programmation et de traitement du signal est écrit en C ++ pour plus d'efficacité. Pour atteindre la précision de l'échantillon, l'interpréteur lua ~ s'exécute nécessairement dans le thread OS audio haute propriété, mais le coût du code interprété est minimisé en appelant uniquement Lua pour les actions de changement d'état planifiées. L'allocateur de mémoire Lua et le garbage collector sont optimisés pour le temps réel1, et les pools de mémoire à liste libre sont utilisés pour les tampons audio et les coroutines pour éviter les appels d'allocation de mémoire illimités.
3. JIT.GL.LUA
jit.gl.lua est une liaison graphique spécifique au langage de script Lua pour l'environnement Max / Jitter 2. jit.gl.lua offre un compromis entre la vitesse d'exécution et la flexibilité lors du développement de routines graphiques 3D personnalisées qui se trouvent entre les objets de patch et Javascript d'une part et les externes C personnalisés de l'autre. jit.gl.lua est également étroitement intégré à la bibliothèque Jitter et en particulier à la partie graphique 3D de la bibliothèque, allégeant une partie du fardeau de l'écriture de routines graphiques 3D.
3.1. Intégration avec Jitter
Les objets dans Jitter dont le nom commence par jit.gl par convention reçoivent tous des notifications d'un contexte graphique donné auquel ils sont attachés. Contrairement à l'objet js (Javascript), jit.gl.lua s'attache à un contexte graphique et fournit des crochets dans l'environnement de script Lua intégré pour recevoir ces notifications qui peuvent être utilisées pour appeler automatiquement le script lorsque le contexte graphique l'appelle ainsi que gérer ressources dépendantes du contexte telles que des ensembles de commandes de dessin stockées dans une liste d'affichage. Les scripts Lua intégrés ont également accès à l'objet jit.gl.lua dans lequel ils sont intégrés via la variable globale this. En définissant les attributs de l'objet d'intégration, l'état OpenGL global peut être géré pour l'ensemble du script et remplacé de manière sélective par des commandes OpenGL de bas niveau pendant l'exécution du script.
En plus de l'intégration avec les contextes graphiques Jitter, jit.gl.lua fournit des liaisons à la plupart des fonctions C de la bibliothèque Jitter normalement accessibles uniquement lors de l'écriture d'externaux C personnalisés. Les bibliothèques les plus importantes pour manipuler des graphiques 3D sont les bibliothèques vecmath et drawinfo. La bibliothèque vecmath est une bibliothèque
mathématique vectorielle et matricielle complète pour les graphiques 3D, gérant des vecteurs de longueur 2, 3 et 4 ainsi que des matrices 3x3 et 4x4. La bibliothèque drawinfo contient des fonctions pour les manipulations de bas niveau de l'objet jit.gl.texture pour lier des textures à une géométrie arbitraire et rendre des commandes OpenGL arbitraires à la texture. Dans jit.gl.lua, les objets Jitter pour le traitement matriciel et les fonctionnalités OpenGL de niveau supérieur sont disponibles de manière similaire à l'objet js avec un certain nombre d'extensions. Tout d'abord, les objets Jitter nommés dans un correctif peuvent être référencés dans un script en utilisant le service de recherche de nom Jitter rendu disponible via la méthode jit.findregistered. Deuxièmement, une liaison étendue de l'objet jit.submatrix permet l'écriture de scripts de routines de traitement de sous-matrice sur place avec tout objet Jitter qui traite les matrices
3.2. Bibliothèques de support
Le langage de script Lua a un système de modules intégré pour charger dynamiquement des scripts formatés en module et des collections binaires de code C / C ++ compilé. Le système de modules fonctionne sur Windows et toutes les plateformes OSX depuis 10.3. Avec le système de modules, des fonctions C / C ++ uniques ou entièrement des bibliothèques peuvent être introduites dans l'environnement Max / Jitter sans avoir à écrire un externe. Cela permet, par exemple, de prototyper des routines de dessin 3D dans Lua, puis de les traduire en C sans avoir à gérer la programmation supplémentaire requise pour développer un objet Jitter à part entière. Des bibliothèques entières peuvent également être importées dans Max / Jitter de cette manière. Certaines bibliothèques actuellement disponibles incluent l'Open Dynamics Engine (ODE) [26], la boîte à outils OpenGL View (GLV) [18] et une bibliothèque Matrix Operation (MOP). Le module ODE apporte un ensemble sophistiqué d'outils physiques à Jitter, qui peut être utilisé pour donner des propriétés physiques aux éléments d'une scène 3D ou
décrire un système physique pour la manipulation de paramètres comme dans les bibliothèques pmpd et msd [10] [17]. GLV est une boîte à outils d'interface utilisateur graphique (GUI) pour OpenGL. Il contient un ensemble extensible de widgets ainsi qu'un système de gestion d'événements avec des routines de dessin personnalisables. Le module MOP est spécifique à Jitter et est destiné à accélérer le développement de routines de traitement matriciel. Il fournit toutes les fonctionnalités nécessaires pour obtenir des données à partir d'une matrice Jitter et laisse à l'utilisateur de fournir simplement la routine de traitement des données.
4. CONCLUSION ET TRAVAUX FUTURS
Nous avons présenté deux extensions de l'environnement de composition multimédia Max qui permettent de nouvelles approches de composition au sein de Max et surmontent certaines de ses limites. Pour les deux extensions, nous avons développé de nouveaux frameworks multimédias pour le langage de script Lua, fournissant des interfaces flexibles et efficaces pour développer de nouvelles œuvres. Bien que lua ~ et jit.gl.lua soient des objets distincts dans l'environnement Max, nous développons une extension pour prendre en charge l'échange bidirectionnel de messages et de structures de données entre les instances de Lua à l'aide de «tubes». Les tubes peuvent être utilisés pour dessiner des graphiques selon des processus audio et vice versa, conduisant à la construction d'entités audiovisuelles fonctionnelles. Un autre objectif est de présenter une plate-forme autonome pour la composition multimédia qui ne repose pas sur Max en tant qu'hôte, fusionnant les fonctionnalités de nos extensions audio et graphiques à Lua.
Les externes sont disponibles pour téléchargement public à: lua ~: http://www.grahamwakefield.net/ jit.gl.lua: http://cycling74.com/twiki/bin/view/Share/WesleySmith 5. REMERCIEMENTS
Merci à Lance Putnam pour la bibliothèque Synz DSP et à l'équipe UCSB MAT GLV pour la boîte à outils GUI.
Merci également au laboratoire UCSB MAT InfoVis. Support partiel fourni par NSF IGERT Grant # DGE-0221713.
6. RÉFÉRENCES
[1] H. Abelson, G. J., Sussman, «Structure and Interpretation of Computer Programs», MIT Press, Massachusetts, États-Unis, 1996.
[2] Alioth, «Computer Language Benchmarks Game», récupéré en avril 2007: http://shootout.alioth.debian.org/gp4/benchmark.php?test= all & lang = lua & lang2 = javascript.
[3] M. Bouchard, «GridFlow 0.8.4 C ++ / Ruby Internals», récupéré en avril 2007; http://gridflow.ca/latest/doc/internals.html.
[4] R. Dannenberg, P. Desain, H. Honing, «Programmation
Language Design for Music »dans Musical Signal Processing, Swets & Zeitlinger, Pays-Bas, 1997.
http://www.music.columbia.edu/~brad/maxlisp/
[6] Garton, B. et D. Topper, «RTcmix - using CMIX in real time», dans les actes de la Conférence internationale sur la musique informatique. Association internationale de musique informatique, 1997.
[7] G. Geiger, Abstraction in Computer Music Software Systems, thèse de doctorat, Département de technologie, Universitat Pompeu Fabra, Barcelone, Espagne (2005).
[8] T. Grill, «Py / Pyext», récupéré en avril 2007; http://grrrr.org/ext/py/.
[9] F. Guerra, «LuaGL», récupéré en avril 2007; http://luagl.wikidot.com/. [10] C. Henry, A. Momeni, «Cartographie dynamique indépendante
Couches pour le contrôle simultané de l'audio et de la vidéo
Synthesis », Computer Music Journal, 30: 1, pp.49–66, printemps 2006.
[11] R. Ierusalimschy, L. H. de Figueiredo, W. Celes, «Lua - an extensible extension language», dans Software: Practice & Experience 26 # 6 (1996) 635-652, 1996. [12] R. Ierusalimschy, «Programming in Lua» (2e éd.) PUCRio, Rio de Janeiro, 2006. [13] R. Ierusalimschy, L. H. de Figueirdo, W. Celes, «The Evolution of Lua», à paraître dans ACM HOPL III, 2007.
[14] D. Manolescu, «Workflow Enactment with Continuation and Future Objects», dans OOPLSA'02, Seattle, WA, 2002.
[15] D. Manolescu, «A Dataflow Pattern Language» dans les actes de la 4e Conférence sur les langages de programmation de programmation, 1997.
[16] J. McCartney, «Repenser l'informatique musicale
Language: SuperCollider », Computer Music Journal 26, 4 (2002), 61–68.
[17] N. Montgermont, «Modèles physiques particuliers en environnement temps réel: application au contrôle des paramètres de synthèse», mémoire de maîtrise, Université Pierre et Marie Curie, Paris, France, 2005.
[18] E. Newman, L. Putnam, W. Smith, G. Wakefield, «GLV - OpenGL Application Building Kit», décembre 2006; http://glv.mat.ucsb.edu/.
[19] M. Pall, «LuaJIT», récupéré en avril 2007; http://luajit.luaforge.net/.
[20] M. Puckette, «Pure Data», dans Actes de la Conférence internationale de la musique de 1997 (ICMC ’97) (1997), Computer Music Association, pp. 224-227. [21] M. Puckette, «Max at Seventeen», Computer Music Journal 26, 4 (2002), 31-43.
[22] L. Putnam, «Synz», récupéré en avril 2007; http://www.uweb.ucsb.edu/~ljputnam/synz.html.
[23] D. Pyon, «Csound ~», récupéré en avril 2007; http://www.davixology.com/csound~.html.
[24] C. Roads, «Microsound», MIT Press, Cambridge, MA, États-Unis, 2001.
[25] Rustak, «WoWWiki, le wiki Warcraft», récupéré en avril 2007; http://www.wowwiki.com/UI_Beginners_Guide.
[26] R. Smith, «Open Dynamics Engine», récupéré en avril 2007; http://www.ode.org/.
[27] W. Smith, G. Wakefield, «Synecdoche», janvier 2007; http://www.mat.ucsb.edu/~whsmith/Synecdoche/.
[28] D. Zicarelli, «Comment j'ai appris à aimer un programme qui ne fait rien» Computer Music Journal 26, 4 (2002), 44-51.
[29] D. Zicarelli, J. K. Clayton, «Javascript in Max», dans Max / MSP Complete Documentation, récupéré en avril 2007;
