INTRODUCTION
The contemporary digital artist can choose amongst many software tools to express his or her idea. The Max family of applications (Max/MSP/Jitter [27], PureData [19], etc.) are popular choices for composing interactive digital media works because of the approachable graphical interface, many bindings to media processes and protocols, and an open-ended philosophy. The Max family implements a visual Data Flow Architecture [15] through a patching interface with both event flow and stream flow. While this type of interface is powerful and flexible, the Max/MSP/Jitter environment also carries some inherent limitations (Table 1). Driven by artistic goals [27], the authors desired a dynamic interface to overcome such issues, supporting both low-level data processing and high-level control. As Puckette notes, an ideal solution is to embed an interpreted language.
LUA~
The lua~ external incorporates domain specific extensions to the Lua language for digital audio.
Surprisingly few such extensions exist (notably Geiger’s research project ALUA [7] and recent high-level bindings for the CSound API) and none that provide the rich degree of control to satisfy the authors’ needs.
Following Lua’s philosophy, the audio domain extensions in lua~ were designed to provide metamechanisms for digital music composition rather than a variety of preconceived musical structures (as appropriate for a domain so fraught with complexity and ambiguity [4]). Computer music compositions may.
Concurrent functional control
Concurrent functional control is based upon an extension of Lua coroutines. A coroutine represents an independent thread of execution for deterministic scheduling (also known as collaborative multi-tasking).
In lua~, such coroutines are extended to be aware of the sample-clock, with a small number of additional functions to interact with the scheduler.
Signal Processing
Because the Max/MSP SDK API does not allow dynamic instantiation of any MSP object, a different set of signal processing unit generators has been provided,based on the efficient C++ library Synz [22]. An SDK to extend the DSP vocabulary is planned as future work.
Signal processing primitives (unit generators) are reated by calling library constructor functions, such as Sine(), Env(), Biquad() etc. The constructor functions may themselves take numeric or unit generator inputs as their arguments, such that for example the statement Sine(Sine(0.1) * 400 + 500) will create a basic FM synthesis graph modulating between 100 and 900Hz ten times per second. Note that basic operators (+, *, -, /,%, ^) are overloaded for unit generators to aid legibility.
Avoiding block-rate
The scheduler algorithm at the heart of the lua~ external manages the coroutines and the signal processing graphs, avoiding block-rate control limitations. The scheduler lazily evaluates graph sections only when deterministically necessary, maximizing vectorprocessing potential where possible. Latency between inputs and outputs is only incurred for graph sections with cycles (feedback), and can be minimized to arbitrary control rates. Lua~ thus permits a sample accurate articulation of the composition that may be dynamically deterministic. State changes that involve interpreted code to generate new signal graphs may occur sub-millisecond rates, ideal for generative microsound [24].
Dynamic graphs & multiplicity
In the Max visual interface, the audio graph cannot be recompiled without audible discontinuities, limiting dynamic audio processing to static, pre-allocated structures. Similarly, the maximum number of parallel voices must also be pre-allocated (e.g. poly~ arguments).
In contrast, lua~ supports generative, dynamic signal graphs without discontinuities.
Optimization for real-time processing
The majority of scheduling and signal processing code is written in C++ for efficiency. To achieve sample accuracy, the lua~ interpreter necessarily runs in the high propriety audio OS thread, but the cost of interpreted code is minimized by only calling into Lua for the scheduled state change actions. The Lua memory allocator and garbage collector is optimized for realtime , and free-list memory pools are used for audio..
JIT.GL.LUA
jit.gl.lua is a 3D graphics specific binding of the Lua scripting language for the Max/Jitter environment .
jit.gl.lua provides a compromise between execution speed and flexibility when developing custom 3D graphics routines that lies between patch objects and Javascript on the one hand and custom C externals on the other. jit.gl.lua is also tightly integrated with the Jitter library and in particular the 3D graphics portion of the library, easing some of the burdens of writing 3D graphics routines.
…
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Using lua for audiovisual compostion (320 KO) (Cours PDF)
