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.

In the very-short-notice department, we’ve been asked to do some kind of live performance/installation for the upcoming Science Museum Late event on September 28th, using the 77-speaker Lottolab Soundwall as the sound system.

Faced with a complete lack of existing material which can be pressed into service in this kind of environment, and also faced with a very tight deadline, the only solution is to quickly assemble a set of tools which can be used to generate and modify musical material quickly and fluidly. This is a good excuse to dust off some sequencing tools which were aired briefly for the Post Me performance project in Prague, plus the Max for Live sample shard processor which has been pressed into service for a few gigs (and which features in a video here). Visual impact is going to be a factor for this gig, so we’re going for this look:

The Straker sequencer already has some bling on the monome 128, but we need to get something up and spinning on the arc 4 in quick order.

(Geek note: in this photo the monome 128 is running Straker, written in Java, with sequencer tracks implemented in Python, while the arc 4 is running an animation demo written in Clojure. Both use the shado rendering library.)

Oh: the Soundwall is apparently OSC-controllable. We may or may not have time to throw some code at that.

We’ve been awarded an artist’s residency at DanceDigital as part of the Digital Futures in Dance National Conference this September. Our mission is to bring the Choreographic Language Agent forward from its current workshopping phase into a state where Wayne McGregor can make use of it in the creation of his new work which premieres at Sadler’s Wells in December. We present the outcomes of the residency on September 9th.

There’s more information about the residency (and the other artists based at South East Dance and Dance South West) here.

(Photo: Jonah Bokaer.)

We are running a workshop on concurrent patchers and data structures with MaxMSP and Clojure at the Cycling ’74 Expo in Brooklyn, October 14-16. Details to follow. For that matter, details to be designed and coded.

Anyone who wants to get a flavour of how the workshop might pan out should check out the existing Python-for-MaxMSP package, and then close their eyes and try to imagine what that might look and feel like if the underlying language were Clojure rather than Python.

I’m anticipating that full-on functional programming techniques will be new to many MaxMSP users, and the uncompromising nature of the Lisp syntax can also be a bit of a hurdle, so I’m planning to spend some workshop time getting up to speed on those aspects before looking at the concurrency features specific to Clojure itself.

We are about to depart to Poland to install the computer platforms for Plenum, showing in Toruń from August 9th. This work by Simeon Nelson is part of the Lux Scientica festival series; the piece moves on to Estonia in September and Durham in November.

Dates:

• 9-13 August, Skyway ’11, Toruń, Poland
• 22-25 September, Valgus Festival, Tallinn, Estonia
• 17-20 November, Lumiere, Durham

Plenum is a revision and extension of an earlier work, Księżyc (The Moon) which premiered at Skyway 10. (Pictures here.) We took the opportunity to rewrite the graphics system for the new version. The original made use of Processing as a renderer embedded within Field, but the bridging wasn’t totally robust, so it made sense to exploit Field’s native rendering system for a less convoluted implementation. Field’s author, Marc Downie, stepped in with a reimplementation of the low-level graphics routines to shift the geometry rendering from Python/Java onto the graphics card, resulting in a rather nippy frame rate, some lovely anti-aliasing (pictured left), and Processing left somewhat in the dust. (There’s a technical write-up here.)

Tallinn is expected to present some interesting challenges: we are anticipating being given access to a forty-metre-high mediaeval cylindrical tower.

We recently participated in a workshop organised by the R-Research arm of Wayne McGregor | Random Dance, teaching the Choreographic Language Agent software to the company. We are now back in software maintenance mode, applying some fixes and enhancements suggested by sessions with the company dancers. Our next period of residence with the company is at Dartington College at the end of August.