NewsWorksSoftwareTextBioContact
background image

Patch substitution in live performance

November 15, 2011

Me and Karen Kipphoff are about to start work on a new project that might become a hybrid stage/installation work, although it is all still quite open.

In the process Karen has started looking into Isodora, as a possible alternative to running live video from Max and Jamoma. I’ve also started taking a look at some of the tutorials. Isadora is a patch-domain program for live video processing, and as such resembles Max, although the modules (or “actors” as they are called) are higher-level functional processing modules rather than low-level building blocks.

The developer, Mark Coniglio, is clearly experienced at live video for stage productions, and it is interesting to take a closer look at the strategies employed for managing patches over time in performance.

One very interesting idea is how patches are conceptualized as scenes. As the play or performance progress, one will move from one such scene to the next, with cross-fading transitions between scenes in much the same way as in e.g. PowerPoint or Keynote.

In Max, I have always ended up with one humonguous patch containing all processing that will ever be needed all the way through the performance, and lots of logistics to handle routing and muting along the way to save CPU and GPU.

One important change in Max 6 is that each top-level patch does audio processing in its own separate thread. Hence audio can be turned on and off independently for each patch. It might be that this opens similar possibilities for patch substitution during performance: All patches could be loaded up-front and positioned off-screen. As they are to be used, they could be moved on-screen, get audio turned on, and then be faded in. Moving on to the next patch, the previous could be faded out again, and then be moved off-screen again.

One could of course also dynamically open and dispose of patches, but based on prior experience, I’m sort of hesitant towards the idea of doing massive memory allocation and freeing in the middle of the heat unless I have to. Anyway all of this is well worth investigating further, and maybe bring into the discussion of possible future directions for Jamoma development.