Jamoma: A Modular Standard for Structuring Patches in MaxSkip other details (including permanent urls, DOI, citation information)
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 3.0 License. Please contact firstname.lastname@example.org to use this work in a way not covered by the license. :
For more information, read Michigan Publishing's access and usage policy.
Page 00000144 system, with a well-defined interface to the other components. The leftmost inlet and outlet of any module is reserved for communication of control information to and from the module using the Open Sound Control protocol (Wright and Freed, 1997). Modules are expected to maintain a record of their current state, and this state can be queried and stored. Modules may define parameters and messages. Parameters alter the state of the module. Arguments passed can be of any type permitted by the Max environment. If a parameter expects a floating point or integer argument, a range can be defined where upper and/or lower limits enforced. In addition, the parameter may be set to ramp to new values over a period of time given as a second optional argument. At this time only linear ramping is supported; more ramping modes will be implemented in the future. Messages behave the same as parameters, except that they are stateless. Optional additional inlets and outlets are used for audio signals or passing video as Jitter matrixes. This can easily be expanded to include other types of data if required. The Jamoma specification poses no restrictions on the number of inlets or outlets used for signals, and neither is it required that the number of inlets and outlets are identical. A module might mix various types of signals, though no such modules are implemented in the current distribution. It is recommended that all modules implement certain standard messages and parameters to ensure that common tasks are dealt with consistently. Additional standard parameters and messages are recommended for audio and video modules respectively. These will be further described in the following sections. Jamoma specifies the user interface to have fixed dimensions based on the paradigm of conventional rack mount hardware. The standard size of a module is 510x60 pixels. Modules might be several rack units tall, and/or a half rack unit wide. The width of 510 pixels was chosen to maximize the number of modules that can fit on a monitor with a resolution 1024 pixels wide, encouraging efficient and consistent use of screen real estate. While this may seem like an unnecessary restriction on first glance, the enforcement of this lattice vastly simplifies organization of modules on the screen for efficient use by both automated and human processes. 2.2 Jamoma Modules A number of externals and abstractions (Max patches made to behave like externals) have been developed to facilitate the development of modules. In Jamoma terminology these are called components. Figure 1 shows jmod.hub, the central brain of the module, jmod.hub maintains all control communication to and from the module, as well as communication to and from other components in the module. It also keeps track of the state of the module, working in tandem with pattrstorage, part of the new regime offered as part of Max/MSP 4.5 for improved state handling. Arguments to jmod.hub are required for setting up local wireless communication of messages within the module, describing the name and size of the module, the number of signal inlets and outlets, what kind of data the module is dealing with, and a description of the module. jmod.hub also has the ability to auto-generate HTML documentation for the module. Fm control information in l control information out algory jithmg algorithm Figure 1. jmod.hub communicates with the outside world, handles internal state, and controls the logical algorithm. Currently three basic types of modules are implemented, dealing with control data, audio and video respectively. Other types of modules might be implemented in the future. Each module is made up of three functional elements. Graphical User Interface (GUI). The graphical user interface provides visual feedback and interaction with the module. The interface aims to provide access to as many parameters of the module as possible, while remaining efficient in terms of screen usage. The jmod.gui component, loaded as a bpatcher, forms the backdrop of the GUI section. Arguments to jmod.hub set the size of jmod.gui, as well as the look, depending on the kind of data the module is processing. Common tasks of modules are implemented as part of jmod.gui. The GUI uses a skinnable system to allow for customization of the look and feel of a module. For audio modules an optional widget offers monitoring of output levels as well as the ability to mix dry and wet signals, mute or bypass the module and change internal sampling rate, as illustrated in Figure 2. |p 1...en,.1"'l Figure 2: The jmod.degrade~.mod emulates use of lower sample- and bitrate. Figure 3 illustrates the pop-up menu shared by all modules. The content of the menu varies depending on the type of module. For all modules, screen updates of the user 144
Page 00000145 interface elements can be disabled to conserve CPU cycles. HTML documentation of the module can be accessed and the algorithm (the internal logic of the module) may be viewed in a separate window. Current state can be saved as an XML preset file, previously saved presets may be loaded, or the default preset recalled. For video modules additional menu items offer possibilities of bypassing, muting or freezing the video processing. accessed from the pop-up menu. The main section of the GUI is reserved for graphical user interface objects for interacting with various parameters and messages specific to the module. The design of this part of the GUI is left to the whim of the module creator. Parameter Handling. The two components jmod.parameter Figureand jmod.Severmessages a nwhat parameters anbe messages the module accepts. They also deal with any boundaries on range and type of argument, as well as the ramping main section of the components might be connected to graphical user interface objects for user interacting with various parameters and messages specific to the modulessly. The design of this parto jmod.hub for of the GUI is left to the rest of the patch, and the outsideor. Parameter Handling. The two components jmod.parameter and jmod.message are used to define what parameters and messages the module accepts. They also deal with any boundaries on range and type of argument, as well as the ramping mechanism. The components might be connected to graphical user interface objects for user interaction and feedback. They connect wirelessly to jmod.hub for communication with the rest of the patch, and the outside world. capability for muting of the algorithm, or downsampling it, to save CPU cycles. In this case the leftmost inlet will be a shared control-data and signal inlet. The algorithm differs as compared to a module by being stateless and not offering any graphical user interface. Documentation. For all modules distributed as part of Jamoma, HTML documentation is provided as well as help patches illustrating the use of the module. There are help patches for custom externals and components. Tutorials are provided on how to build modules, and templates for modules are provided to simplify the process. 3. Examples of Usage 3.1 Controlling Jamoma Modules Modules might be controlled in a number of different ways. A system for remote communication enables a set of control modules for controlling other modules. Several such modules are implemented. jmod.cuelist.mod loads a textbased script of event cues, and is able to control all modules provided that they have been given unique names via Max's script-name inspector. The cues can be executed in arbitrary order. A WAIT syntax can set the execution of a cue on hold for a specified amount of time, opening up the possibility for scripting of complex events evolving over time. The current state of all modules can be queried, and used to create new cues. Figure 5 provides a simple example. CUE sweep U- -U UU- -- --U U U--- - -U U- - -- - HUU U UU U - Figure 4. A stereo algorithm for audio degrading. Algorithm. The logical task of the module is generally implemented as a subpatch and saved separately. Figure 4 shows one such subpatch, or algorithm, for a simple audio processing module. The algorithm shares several conventions with the module. The leftmost inlet and outlet is used for communicating control data to and from the algorithm using Open Sound Control messages. Additional inlets and outlets are used for passing audio and video signals to and from the algorithm. Audio algorithms can be loaded in the module using the poly~ external, incorporating the possibility of several parallel instances as well as the # Module filter/filter-/cf 3000 3000 WAIT 6000 /filter-/cf 200 3000 Figure 5. A cuescript. The center frequency of the filter~ module ramps to 3000 Hz over 3 seconds, holds for 3 seconds, and ramps down to 200 Hz over 3 seconds. Other control modules exist for mapping of parameters between different modules, and for enabling network communication using Open Sound Control. Such modules are able to control themselves as well, offering possibilities for complex recursive generative systems. 3.2 Various approaches to using Jamoma The Jamoma distribution includes a number of modules, and more modules will be added in the future to form a library targeting a number of specific and common tasks for audio and video processing. For experienced users of Max/MSP/Jitter the structure itself and the possibilities for control offered may be more interesting than the included modules themselves. In performance Jamoma offers efficient use of screen estate, a 145
Page 00000146 standardized way of dealing with presets and parameter handling, and simplifies complex handling of parameters. The authors have found that modules ported to Jamoma tend to maintain more of the possible parameters available for interaction than when working with unstructured Max patchers, resulting in richer expressive possibilities. In large projects involving several artists or programmers Jamoma offers a standardized framework to simplify collaborative development. As Jamoma uses Open Sound Control it is simple to extend the system to large projects running on a network of connected computers. For newcomers to Max/MSP/Jitter Jamoma can simplify the process of structuring patches so that they become useful and reliable. It is the authors' hope that the Jamoma structure will encourage reuse and exchange of modules within the Max community. In the case that one does not want to adapt to the modular structure of Jamoma, the underlying algorithms might still prove useful as lower-level building blocks. The guidelines might be useful on their own, and could be extended/adjusted to work with other programs for audio processing. This could eventually be extended into a partly standardized OSC namespace. 3.3 Jamoma modules as plugins To demonstrate the flexibility of Jamoma, the official distributions contain two examples of how to use Jamoma modules in Pluggo-based5 plug-ins. Pluggo provides a system whereby Max/MSP patches can be transformed into plug-ins usable in any VST, AudioUnit, or Pro-Tools host. By using Pluggo's objects together with Jamoma it is possible to quickly create complex and powerful plug-ins for music production environments. 3.4 Obtaining Jamoma As of this writing Jamoma version 0.3.1 is publicly available for Windows XP and Mac OSX Universal Binary from the Jamoma web site6. In spite of the low version number, extensive development has been carried out. The development of the Jamoma specification and implementation has, to a large degree, been informed by concerts, performances and installations by the authors and others. Jamoma has proven a stable tool expanding artistic flexibility and possibilities. Jamoma is licensed under the terms of the GNU Lesser General Public License7. 4. Further Development Further development on the kernel will focus primarily on performance improvements, possibly by porting many patcher components to C-based externals. The support of additional parameter ramping modes will allow both more flexibility and better performance. In addition support is planned for non-real-time rendering of audio and video. Remaining improvements will be focused on the module-level. For control modules this includes additional automation facilities and paradigms, and different approaches to handling time-based works. Current audio module development includes work on spatialisation, effect processing, and synthesis facilities. Modules for spatialisation will offer access to several different techniques, including vector based amplitude panning (Pulkki, 2000) and ambisonics (Schacher and Kocher, 2006). Video module development is currently focused on analysis of gestures, with The Musical Gestures Toolbox (Jensenius, God0y and Wanderley, 2005) being ported to Jamoma. There is an ongoing dialog with the Integra8 project led by UCE Birmingham Conservatoire to ensure compatibility between the two projects. 5 Acknowledgments The Jamoma project wishes to thank Electrotap for providing the initial resources for the project and for open sourcing software required by Jamoma. Development has been sponsored in part by Bergen National Academy of the Arts as part of a research fellowship in the arts. The jamoma.org website is hosted by Bergen Center for Electronic Arts. Additional support has been provided by Alexander Refsum Jensenius, Jeremy Bernstein at Cycling '74, and the members of the Jamoma SourceForge project. References Jensenius, A. R., R. I. God0y and M. M. Wanderley. 2005. Developing tools for studying musical gestures within the Max/Msp/Jitter environment. In Proceedings of the International Computer Music Conference 2005, pp. 282-285. Barcelone, Spain: International Computer Music Association. Manovich, L.,2001. The language of new media. Cambridge, Massachusetts: MIT Press. Pulkki, V, 2000: Generic panning tools for MAX/MSP. In Proceedings of International Computer Music Conference 2000. pp. 304-307, Berlin, Germany: International Computer Music Association. Schacher, J. C. and P. Kocher, 2006: Ambisonics Spatialization Tools for Max/MSP. In Proceedings of the International Computer Music Conference 2006, New Orleans, US: International Computer Music Association. Wright M. and A. Freed. 1997. Open sound control: A new protocol for communicating with sound synthesizers. In Proceedings of the International Computer Music Conference 1997, pages 101-104, Thessaloniki, Greece: International Computer Music Association. Zicarelli, D. 2002. How I Learned to Love a Program That Does Nothing. Computer Music Journal 26(4), 44-51. 8 http://www.integralive.org 5 http://www.cycling74.com/products/pluggo 6 http://www.jamoma.org 7 http://www.gnu.org/copyleft/lesser.html 146