We’ve just started work on a multichannel sound score for Shobana Jeyasingh’s new dance work TooMortal, a site-specific piece for historic churches in the UK, Venice and Stockholm.

Dates

• 14th-16th June: Venice (site tbc.).

• 28th-30th June: St. Mary’s Old Church, London.

• 12th-14th July: St. Pancras Church, Euston.

• 19th-21st July: St. Swithun’s Church, Worcester.

• 12th-13th September: Stockholm (site tbc.).

(Photo: JP Masclet.)

We’ve just uploaded a Morse code generator for Overtone.

I’ve never been much of a fan of SuperCollider largely because of its front-end language, which I first encountered around 15 years ago (before SuperCollider even existed) and had various issues with, but Overtone (a Clojure environment for driving the SuperCollider audio engine) is a different proposition.

I’m working on a project involving online avatars and audio-rate control systems, and since Clojure+Overtone can clearly do both web interfacing and audio (all with decent multithreading semantics) it avoids the need for separate programs hooked together via OSC or any kind of plug-in or hosting setup. (We’ve already implemented Clojure for MaxMSP, and that was lined up as our Plan B.)

This Morse code generator is very much My First Overtone Program, drawing just on basic Overtone/SuperCollider idioms which I can hack together without getting too lost. Most of it is plain old Clojure coding with a bit of event scheduling, familiar from realtime media applications.

I wonder how much SuperCollider I’d have to learn to add synthetic shortwave radio interference?

The Wellcome Trust-funded installation piece Anarchy in the Organism by Simeon Nelson has just gone live at the UCLH Cancer Centre. We designed and built the animation and rendering system; Rob Godman composed the multichannel soundtrack.

Here’s a test render of a short section of one animation screen, running faster than the default animation speed of the piece:

We’ll follow up with technical details in due course, but in the meantime here is a gallery of shots of the installation phase:

We are giving a short presentation at the next Makers’ Guild event: Making Sounds at the V & A on April 13th. Topics to be covered will probably include recent work with Monomatic and a bit of show-and-tell of performance techniques with the monome.

As half of Monomatic, I contributed an algorithmic video piece to a set of works entitled Whitney Evolved, projected at the Kinetica Art Fair last month. (Other contributors included Lewis Sykes, Evan Raskob, Mick Grierson and Paul Prudence.) Each work was inspired by the early animation work of John Whitney Senior, much of which was done using mechanical equipment many years before computers became powerful enough to render his images in real time.

This particular piece takes Whitney’s basic “rose” pattern and duplicates it into translucent layers of discs, rotating at arithmetically related speeds so that the layers drift into and out of various patterns of alignment. The virtual camera performs a continuous slow pan around the structure from poles to equator, its distance varying as it orbits.

Technology: the Whitney algorithm is written in Clojure and hosted in Field, which takes care of the OpenGL display. Projection in the P3 Ambika space courtesy of a pair of the inevitable Barco FX-20s.

Recently we’ve been working on several digital art projects using Field as a development and presentation platform but with Clojure running the core, domain-specific algorithmic code. This choice is, admittedly, partly because Clojure is new and shiny, but we also like the Emacs- and Leiningen-based development environment (complete with continuous integration testing), and Clojure’s clean functional semantics lends itself to realtime, evolutionary artworks. Since Field works at the level of Python-on-Java (via Jython), and Clojure runs in the JVM, the Python and Clojure worlds inevitably collide.

Field hosts Clojure directly – in fact, it hosts several JVM-based languages – using something called Text Transforms. Activate the Clojure transform, as in the splash image above, and execution flips from Python to Clojure and back again. The transform passes Python bindings into the Clojure namespace, and bindings made within Clojure are passed out again (within a dedicated variable called _clojure). Both Python and Clojure have access to anything the JVM can see via its classpath. There are one or two wrinkles (such as the hack, shown above, of making sure a variable is retrieved from the Python world before its first use in the Clojure world, since Field’s dynamic lookup machinery only works for Python), but everything pretty much just works.

If we’re developing in two languages at once, we need to be able to pass information between them, not least configuration information from Python into Clojure. In Python, we organise our manifest constants without polluting the top-level namespace by declaring things like this:

m_Configuration = Manifest(
    FULL_CANVAS = False,
    DO_VORONOI = True,
    TREE_DEPTH = 5,
    FIELD_TIMER_INTERVAL = 0.033,
    ASSETS_DIR = "/Users/nick/CASSIEL/FIELDWORKSPACE/"
)

m_Nested = Manifest(
    A = Manifest(B = 6, C = "Hello"),
    D = Manifest(E = False),
    L = [1, 4, 9, Manifest(Z = 14)],
    L_L = [[1, 2], [3, 4, [5]], 6, []],
    N = None
)

This lets us use names like m_Configuration.TREE_DEPTH (value 5) or (if we use our rather implausible test declaration) m_Nested.A.C ("Hello"). The Python for Manifest is pretty simple:

class Manifest:
    def __init__(self, **kw):
        for k in kw:
            setattr(self, k, kw[k])

So what of the Clojure world? Passing a Manifest into Clojure exposes an object constructed from numerous Jython components, whereas what we really want is Clojure hash maps with keywords, so that we can write things like (:TREE_DEPTH m_Configuration) or (:C (:A m_Nested)). So, here’s an implementation of something we call hashify:

(ns oncotrees.util
  (:import [org.python.core PyFloat PyInteger PyBoolean PyString
            PyList PyInstance PyNone]
           [java.util NoSuchElementException]))

(defn hashify [py-object]
  (cond (instance? PyNone py-object) nil
        (instance? PyInstance py-object)
        (letfn [(retr [key] (.__getitem__ (.__dict__ py-object) key))
                (de-iter [iter result]
                  (let [n (try
                            (.next iter)
                            (catch NoSuchElementException _ nil))]
                    (if (nil? n)
                      (reverse result)
                      (recur iter (cons n result)))))
                (lookup [key]
                  (let [p (retr key)]
                    (condp = (class p)
                        PyFloat (.asDouble p)
                        PyInteger (.asInt p)
                        PyBoolean (.__nonzero__ p)
                        PyString (.asString p)
                        PyList (map hashify (de-iter (.iterator p) nil))
                        (hashify p))))]
          (reduce (fn [m k] (assoc m (keyword k) (lookup k)))
                  (hash-map)
                  (.keys (.__dict__ py-object))))
        :else py-object))

We scan through the keys, turning each one into a Clojure keyword and converting its value (recursively, so that we can handle nested manifest objects and lists). The conversion from Java iterator into Clojure list is rather ugly – I’m a bit surprised that there’s no pre-existing support for this.

Looking back at the Field listing at the top: we pass the various manifest objects as arguments to top-level Clojure functions which are higher-order and hence return the actual functions we call from Python, having hashified the manifests. Here’s the main function from a current artwork:

(defn kick
  [m_Configuration m_Geometry]
  (let [{:keys [DO_VORONOI TREE_DEPTH BRANCH_BEND_PATHS]}
        (u/hashify m_Configuration)
        {:keys [CELL_ROWS CELL_COLS CELL_SIZE DELTA
                INITIAL_LEN LEN_MUL]}
        (u/hashify m_Geometry)]
    (fn [t]
      (let [v-fn (if DO_VORONOI
                   (voronoi-with (* CELL_COLS CELL_SIZE 1/2)
                                 (* CELL_ROWS CELL_SIZE 1/2))
                   no-voronoi)]
        (v-fn t
              (d/fixed CELL_ROWS CELL_COLS CELL_SIZE)
              (fn [t] (let [depth-here TREE_DEPTH
                            tip 1
                            tree0 ((d/tree DELTA LEN_MUL tip BRANCH_BEND_PATHS)
                                   t depth-here 0 [0 0] INITIAL_LEN nil)
                            tree1 (map rotate-R tree0)
                            tree2 (map flip-seg-Y tree0)
                            tree3 (map (comp flip-seg-X flip-seg-Y) tree0)]
                        (cons [[0 0] [0 0]] tree1))))))))

The big win here is the ability to map-bind the entries of a manifest in one go. Using the :keys form here binds the names directly, at the cost of a pile of ugly upper-case identifiers in the middle of the code – but there’s no reason why we couldn’t modify hashify to downcase everything.

The final push: it makes sense to pass composite data objects from Clojure back to Python in the same form (rather straining the original intent of “manifest”), but how do we turn Clojure’s persistent hash maps back into manifest objects? It would be great if we could overload the Manifest constructor to take a hash map; since we can’t, this is the closest I managed to get: an optional non-keyword argument which can be a hash map. Manifest now looks like this:

from java.util import Map, List

class Manifest:
	def __init__(self, h=None, **kw):
		for k in kw:
			setattr(self, k, kw[k])

		if h is not None:
			for k in h.iterator():
				n = k.getKey().getName()
				v = k.getValue()
				setattr(self, n, self.__unpack(v))

	def __unpack(self, x):
		if isinstance(x, Map):
			return Manifest(x)
		elif isinstance(x, List):
			return map(self.__unpack, x)
		else:
			return x

This is effectively “unhashify” on the Python side (and again it’s recursive to handle nested structures). The instance check for Map gets us hash maps; the instance check for List gets us Clojure lists, vectors and sequences. The only real Clojure-dependent part of this is the .getName() call on the keywords to turn them back into strings. (Again, we’d probably want to upcase these to be typographically correct.)

We’ve been putting some effort in recently to shift our major JVM-hosted MaxMSP projects to GitHub. Most of them started out hosted privately in CVS and built using Eclipse, and then migrated to hosting in Mercurial, with a different directory structure and a fair degree of pain in getting the various Ant scripts to work again. Moving everything to GitHub made sense, but that required another rearrangement of source directories and build paths, so it was obviously time to bite the bullet and use Maven to build everything instead. This decision has lowered the maintenance effort considerably.

Without further ado:

• net.loadbang.lib base libraries used by everything else

• net.loadbang.osc a simple but versatile and well-documented OSC library, supporting UDP and TCP transmission and reception

• net.loadbang.scripting a support library for the various JVM-hosted scripting languages

• net.loadbang.groovy the Groovy language for MaxMSP

• net.loadbang.jython the Python language for MaxMSP, using the Jython system

• net.loadbang.shado a high-level sprite-based rendering library for the monome and arc control surfaces

A few things are still missing from this list:

• SQL a wrapper on top of some zero-footprint SQL databases (plus a MySQL shim): with the advent of Python and Clojure as DSLs for Java, it’s not clear that this package serves any real purpose

• net.loadbang.straker a not-yet-released modular sequencing framework for the monome

• net.loadbang.fireflash a not-yet-released multi-app, multi-device heterogeneous monome protocol router

• web an embedded Jetty-based web server for Max

• various user-interface goodies like Nixie tubes and rotating text

• Clojure – the most important at this stage - Clojure for MaxMSP

Clojure will be getting some love very soon (we’re teaching it in about three weeks). The link above is to an early build we put together for the Cycling ’74 Expo last October; it still needs to be Mavenised and updated for Clojure 1.3.

Some videos: this is what straker looks like when it’s running (a sight familiar to recent audiences at the Lottolab gigs):

This is fireflash:

]]> http://www.cassiel.com/2011/12/22/loadbang-reloaded/feed/ 0 http://www.cassiel.com/2011/12/13/maxmsp-showing-and-telling/ http://www.cassiel.com/2011/12/13/maxmsp-showing-and-telling/#comments Tue, 13 Dec 2011 23:17:24 +0000 nick http://www.cassiel.com/?p=257

We’re workshopping, and gigging, at the M4_u (Max/MSP for Users) Convention, 13th to 14th of January, Phoenix Square, Leicester. The workshop is pretty much going to be a repeat of that given at the Cycling ’74 Expo – building an algorithmic step sequencer and abstract display system using Clojure. The gig will be monome-based, probably with some pulse sequencer action.

This short video shows Plenum projected onto St. Oswald’s church as part of the Lumiere Durham festival. This was the third outing for the piece this year, the first two being at Skyway (Toruń, Poland) and Valgus (Tallinn, Estonia), associated with Lux Scientia.

As mentioned in an earlier blog entry, This version of Plenum dispenses with the (rather fragile) Processing plugin for graphics and instead uses Field‘s own antialiased scenegraph renderer. Having something resolution-independent with a virtual camera and the ability to render onto a foldable frame buffer surface was a great help when it came to calibrating for the Tallinn town hall. (We aren’t doing projection mapping, and have no intention of being drawn into that area until a convincing, coherent creative process presents itself.)

The overall timeline arc – the disintegration of a matrix into gravitationally orbiting and escaping bodies – is much the same as the version developed for Skyway in 2010, but the current version also employs a complex, dynamic set of mutation functions which change the sizes of the points according to geometric formulae, resulting in visual artifacts (rings, bars) overlaying the disintegration of the basic pattern.

As before, the Field system transmits musical cues and control signals via OSC to a synthesis system designed and programmed by Rob Godman.

(The cryptic diagram in the left hand margin is Field’s sequencing canvas for Plenum, showing the various elements of the piece along a timeline.)

We recently did a bit of coding for Dreamhub: the Lysets Lyd chill-out gig at Vor Frue Kirke required twelve Percussa AudioCubes connected into an Ableton Live set, capable of sending MIDI data to Live (to trigger clips from the sensors) and of responding to MIDI (to transform automation controller messages into colour changes). Percussa’s bundled control software wasn’t up to the task at the time, being limited to four cubes at once and a rather laborious manual setup procedure, so we built a custom Max patcher using an external object by Thomas Grill and our Python machinery to deal with the configuration and state transitions required by the set.

Here’s the obligatory patcher screen shot:

There’s a nice write-up here. Next performance: 3rd February 2012.