David Brooke Wetzel

Interactive Event Manager (IEM)

Scriptable, modular environment for interactive computer music (in Max/MSP)
by David Brooke Wetzel
[printer-friendly version]

Overview of IEM

The Interactive Event Manager (IEM) is a set of signal processing, synthesis, and control modules that are instantiated and controlled by a central "main" application, according to a user-prepared "event script" or by direct input (GUI and command line). IEM began around 2006 as a strategy for re-using components from numerous works for clarinet and interactive electronics. The first IEM prototype was presented in 2007 at the SEAMUS National Conference in Ames, IA. An updated version was shown at SEAMUS 2008 in Salt Lake City, UT. The current version was the subject of a demonstration session at ICMC 2009 in Montreal, QC, and was most recently used in performance for the premiere of Pan's Music Imparts Form to Primal Matter by Andrew Walters (March 2010, Mansfield University) and for a subsequent performance at Electronic Music Midwest (October 2010, Lewis University).

The concept is fairly simple: modules are created as Max/MSP patchers to be instantiated by the IEM system as abstractions (this approach could be considered a type of "plug-in" architecture). Each module contains data and signal inlets and outlets that are dynamically named a) upon instantiation, b) through script commands, or c) by command line input. All other data used by a module for its internal processing remains local, in order to avoid conflicts with simultaneous instantiations of the same module. Virtually any Max/MSP patcher can be quickly and easily adapted as an IEM module.

Development of IEM

I have developed the IEM as a method for streamlining and consolidating interactive computer music environments for my own repertoire of works for clarinet and interactive electronics. This is an outgrowth of my 2004 DMA document in which I analyzed the electronic elements of four works that required now-obsolete technology: Thea Musgrave's Narcissus (1987), Bruce Pennycook's PRAESCIO IV (1990), Jonathan Kramer's Renascence (1974), and Cort Lippe's Music for Clarinet and ISPW (1992). Two of those works (Musgrave and Pennycook) were subject to reconstruction (in Max/MSP) and performance as part of my 2004 DMA lecture-recital. These four pieces were my starting point for IEM.

Reconstruction of an existing work using IEM requires a clear understanding of the technical requirements of the piece and the functions of the original equipment. IEM makes a fairly clear distinction between the "instrument" (a set of modules) and the "score" (a list of connections between modules and a list of commands and state changes within these modules). Many older works require either a dedicated software application for performance (instrument/score in one) or specialized machines that may not be available for performance (and sometimes both). In my experience, even the most complex dedicated system (e.g. Lippe's "ISPW" pieces) can be broken down into discrete components that may be reconstructed in generalized form as re-usable modules.

The musical work that started me on this path, Thea Musgrave's Narcissus, is one that is quite popular among performers, even if it is not "advanced" in its use of interactive technology: a simple digital delay with delay-time modulation, delay-hold, and delay feedback is all that is required. For performers, however, it presents an interesting challenge: the score was written with a specific digital delay in mind, the Vesta Koza "DIG-411," which is extremely hard to find presently, and was fairly rare at the time of the work's composition in 1986-87. Knob positions for the DIG-411 are given throughout the score. The composer states in her technical notes that any capable delay unit may be used, and although most of the delay system variables given can be translated fairly easily to any other delay processor, one in particular, the "modulation" effect, is difficult to emulate accurately without more information than is provided in the score. In my dissertation research, I spoke to several performers involved in the creation and premiere of this piece (special thanks, F. Gerrard Errante, Wendy Rolfe, and McGreggor Boyle) and tracked down the original DIG-411 for analysis. Where Musgrave's score lists mod values (speed= "0" and depth = "1") with no description of how it should sound or how deep a depth value of "1" should be, analysis of the original equipment was most enlightening (for instance, on the front panel of the actual unit, the lowest speed setting is listed as "0.1 Hz," not "0" as described in the score). My first software reconstruction was an attempt to emulate the functions and sound of the DIG-411 in Max/MSP. The result was a dedicated system capable of playing only this one piece. An updated version has been used by numerous performers worldwide. The latest version of this piece is constructed with IEM modules, including a generalized delay module and a "DIG-411 emulator" as a control interface (for convenience). The accompanying event script allows the user to input Musgrave's settings (DIG-411 values) as a series of score events. The IEM "DIG-411 Emulator" module takes care of translating DIG-411 values (e.g. "delay time" as the product of two values, "range" (2, 8, 32, 128, 512) and "time" (0.5 - 2.0)) into standard digital delay parameters. Should the performer wish to alter the settings during rehearsal or performance, event list values may be changed by editing a simple text file. More complex interactive control of delay parameters is also possible, without fundamentally altering the basic system. For the performer, there is no "Max patching" required.

IEM modules

An IEM module is any Max/MSP patch that is instantiated within the IEM network. It communicates with the rest of the network by way of dynamically named "forward" and "receive" objects. One "receive" object is set with a name given as an argument upon module instantiation. This is the address to which parameter/value messages are sent from the event script (and possibly from other modules). Messages arriving at this input are parsed for named parameters within the patcher, and values are distributed accordingly. Data inputs/outputs are named as patcher parameters. These become data inlets/outlets for a patcher that connect to any other module with a like-named inlet/outlet. The same system is used for creating audio connections between objects (using "send~" and "receive~"). The following example shows how two modules connect using named "control data channels."

Example 1:

VK Emulator midule (IEM)
IEM delay module

For a little more fun (assuming you have the full version of Max/MSP), create a new patcher and instantiate each of these new modules as an abstraction by typing the filename in an object box, followed by a name that will identify this instance (e.g., "delay.iem foobar"). Note when you open the module (by double clicking on its box) all instances of #1 are now replaced with the name you gave it as an argument upon instantiation. This includes a "receive" object that feeds in to a subpatcher that parses an incoming list and distributes parameters values to the appropriate locations in the patcher by way of "pvar" (a very handy way of accessing data anywhere in the patcher while still keeping it strictly local).

Now create a "send" object set to the name of your new module (e.g., "send foobar"). connect a message box to it and fill it with the example 1 message (above) or a message to set any of the parameters listed in the module's help window (click on the "?" button). This is how the IEM main communicates with all current modules (except that IEM Main uses "forward" instead of "send" so the destination can be changed dynamically with each line of the event script).

IEM demo test

The Event Script

An event script for IEM is a text file containing a list of messages to be sent to IEM modules. Each line may be addressed to a single module (by instance name), and is proceeded by and event number (e.g., "1 delay1 time 512"). Multiple lines may share an event number, so multiple messages may be grouped and sent out to the network at the same time. Modules may be instantiated and destroyed through messages to "main." Parameters for each module can then be set, including input/output channels and audio busses. Therefore an entire network of iem modules may be instantiated and configured within a few lines of the script. A new script may be loaded following a "main newlist " message. This is useful for placing setup functions in one script and performance events in another. comments may be added on a separate line with "//" in place of an event number.

Example 2

(N.B.: at this time, event scripts are formatted for the Max "coll" object: each line begins with an index number followed by a comma, and terminates with a semicolon)

IEM Main

IEM Main is the central processing module of the IEM network. It is launched as a Max patcher or as a stand-alone application. IEM Main handles event script loading/parsing and instantiation of modules. It is itself scriptable like any other module in the network. Script messages to IEM main begin with "main" followed by a list of parameters and their values (e.g., "main event 3" sets the current event number to 3 and executes event 3 of the currently loaded script. "main newmod delay.iem delay1" instantiates a new module called "delay1"). IEM Main also provides a basic user interface for controlling progress through the event list and loading/viewing scripts and script events. The following example is a complete working system for the setup and performance of Thea Musgrave's Narcissus.

Example 3

This is a complete working system (download the .zip file: IEM-Narcissus.zip) for performing Thea Musgrave's Narcissus using IEM.

    Instructions:
  1. Launch IEM Main (IEM_MAIN_0.7.maxpat).
  2. Click on the "load event script" button and select the "Narcissus-setup" file.
  3. Click on the "Next" button to advance through the list, and note the "current event" table as you progress through the list.
  4. At the end of the setup file, the line "main newlist Narcissus-play.txt" appears. When this event executes, the event script will be replaced and the system is ready for performance.
  5. Click through the performance list and observe how the DIG411 emulator updates.
  6. If you have footpedals connected, you might be able to operate the hold, bypass, and volume controls (look at the "pedals" module by clicking on its name in the list of "Current Modules").
  7. If you want to change anything in the setup (MIDI controllers for instance), simply change the appropriate values in the setup script and run it again.
  8. Alternatively, you can type in your own messages in the IEM Main command line. Start with the module name to address and a list of parameters and their values (e.g., "pedals cc1 64 cc1.chan 2 cc1.port 3").

Here's how it should look:

IEM Main

Here is the "newmod" subpatcher that contains the newly instantiated modules:

IEM newmod subpatcher

IEM for New Composition and Collaboration

Because IEM re-uses modules for functions (sound I/O, foot pedal control, standard DSP effects) commonly found in most interactive systems, it provides a ready framework for constructing and testing new configurations quickly and easily. New and innovative processing ideas can be incorporated into the IEM system by adapting simple Max/MSP patchers as IEM modules. In other words, while the IEM system so far includes a library of basic modules (sound I/O, MIDI control, data monitoring, and signal processing functions adapted from particular works), new ideas can be easily dropped into the system by encapsulating unique functions into a patcher and adapting it for use as an IEM module.

In my recent collaboration with composer Andrew Walters on Pan's Music Imparts Form to Primal Matter (for clarinet, bass clarinet, and interactive electronics), IEM was used as the main vehicle for performance. The piece was composed separately, before a performance interface had been constructed. This project therefore represents a traditional ("classical") model of composition applied to interactive computer music: the composer writes a score, perhaps containing some innovative techniques or musical ideas, and hands it to the performer, who is in charge of realizing it in performance. Walters gave me a score, a Max patch that demonstrated a very interesting synthesis instrument (based on fffb~), and a set of sound files (based on samples of my bass clarinet playing) intended for playback during performance. These are the elements that were new or unique to Walters' composition. Other required elements, such as a delay processor (a featured effect), a pitch tracker (used for controlling the fffb~ synth), sound file playback, sound I/O, spatialization, and MIDI foot pedal control were set up and configured using pre-existing IEM modules. I adapted Walters' prototype fffb-based subtractive synth as an IEM module and incorporated it into the system by adding a few lines to the setup event list.

Example 4

A complete, working version of this system (for performance of Andrew Walters' Pan's Music Imparts Form to Primal Matter) is available here: iem-example4.zip

N.B.: You will need Miller Puckette's fiddle~ object for the pitch tracker to work properly.

Make sure all downloaded files are placed within the Max/MSP search path!

Contents:

Instructions:

  1. Launch IEM Main (IEM_MAIN_0.7.maxpat).
  2. Click on the "load event script" button and select the "Pan-setup" file.
  3. Click on the "Next" button to advance through the list, and note the "current event" table as you progress through the list.
  4. At the end of the setup file, the line "main newlist Pan-events.txt" appears. When this event executes, the event script will be replaced and the system is ready for performance.
  5. Click through the performance list and observe how the "filter" module updates.
  6. If you have footpedals connected, you might be able to operate the hold, filter enable, and event progress controls (look at the "pedals" module by clicking on its name in the list of "Current Modules").
  7. If you want to change anything in the setup (MIDI controllers for instance), simply change the appropriate values in the setup script and run it again.
  8. Alternatively, you can type in your own messages in the IEM Main command line. Start with the module name to address and a list of parameters and their values (e.g., "pedals cc1 64 cc1.chan 2 cc1.port 3").
  9. When you reach event #4 in the "Pan-events" script, you should hear sound file playback (assuming audio is turned ON).

Video links: premiere performance of Pan's Music Imparts Form to Primal Matter | informal tour of the performance setup

Further discussion ...

In the latest version if IEM, script handling, module instantiation and tracking, and message processing by individual modules are handled in a particular way that is at the moment quite specific to Max/MSP. However, the concept of the IEM could be implemented on any platform, and the examples patches shown are merely my latest strategy for implementing the general concept in Max/MSP.

I have had several requests for an "API" to guide others in creating and contributing new IEM modules. Nothing so formal is required, but I do intend to release a template (containing the "vman" implementation) and a tutorial outlining the general guidelines for controlling data flow among instantiated modules. Also, full documentation of the current modules in my toolkit is coming soon.

Some other plans for improvement: currently, the central event list processor must scan through the entire list looking for matching event numbers each time and event trigger is received. For shorter event lists, this is not much of a problem. For longer lists, this might begin to introduce performance lags. I have a concept for pre-processing the event list that I think will prove useful, but it will need some time for development and testing. For now, the system seems responsive enough (speaking as a performer using it on stage). As I tackle more complex systems with longer event lists (such as Cort Lippe's ISPW pieces), this might become an issue. For now, there is of course the technique of using shorter event scripts and dynamically moving from one to another (using the "main newlist [filename]" function).

Articles on IEM

© 2010 David Brooke Wetzel