Monthly Archives: June 2013

Teaching at the Düsseldorf Institute for Music and Media

Last week I was kindly invited by Julian Rohrhuber to do a couple of talks and teach a livecoding workshop alongside Jan-Kees van Kampen at the Düsseldorf Institute for Music and Media. Jan-Kees was demoing /mode +v noise a Supercollider chat bot installation using IRC, so it was the perfect opportunity to play test the work-in-progress slubworld project, including the plutonian botzlang language. It also proved a good chance to try using a Raspberry Pi as a LAN game server.

IMG_20130620_163002

There wasn’t enough time to get deeply into botzlang, but we were able to test the text to sound code that Alex has been working on with a good sound system, and the projection of the game world that visualises what is happening based on the Naked on Pluto library installation:

world5

The Raspberry Pi was useful as a dedicated server I could set up beforehand and easily plug into the institutes wireless router. We didn’t need to worry about internet connectivity, and everyone could take part by using a browser pointed at the right IP address. With access to the “superuser” commands from the Naked on Pluto game, the participants had quite a bit of fun making objects and dressing each other up in different items, later making and programming their own bots to say things that were sonified through the speakers.

Plutonian Botzlang

Plutonian Botzlang is a new language I’m working on for a commission we’ve had from Arnolfini and Kunsthal Aarhus. The idea is to make the Naked on Pluto game bots programmable in a way that allows them to be scripted from inside the game interface, able to inspect all the objects around them and carry out actions on the world like a normal player. We can then strip the game down and make it into an online multiplayer musical livecoding installation.

Bots can be fed code line by line by talking to them, started and stopped and pinged to check their status. I toyed with the idea of making a one-line programming language with lots of semi-cryptic punctuation but opted instead for something a bit simpler and longer, but requiring line numbers.

Here is an example program that looks in the current node, or room for Bells, picks them up if found then saying their descriptions. Each time it loops it might drop the Bell and walk to a new location. This results in bots that walk around a game world playing bells.


10  for e in node.entities
20     if e.name is Bell
30        pickup e.name
40     end
50  end
60  for e in this.contents
70     say e.desc
80  end
90  if random lessthan 5
100    drop Bell
110    walk
120 end
130 goto 10

Here is a screenshot of the modified version of the game with a bot being programmed:

world4

A fluxus workshop plan

I’ve been getting some emails asking for course notes for fluxus workshops, I don’t really have anything as structured as that but I thought it would be good to document something here. I usually pretty much follow the first part of the fluxus manual pretty closely, trying to flip between visually playful parts and programming concepts. I’ve taught this to teenagers, unemployed people, masters students, professors and artists – it’s very much aimed at first time programmers. I’m also less interested in churning out fluxus users, and more motivated by using it as an introduction to algorithms and programming in general. Generally it’s good to start with an introduction to livecoding, where fluxus comes from, who uses it and what for. I’ve also started discussing the political implications of software and algorithmic literacy too.

So first things first, an introduction to a few key bindings (ctrl-f fullscreen/ctrl-w windowed), then in the console:

  1. Scheme as calculator – parentheses and nesting simple expressions.
  2. Naming values with define.
  3. Naming processes with define to make procedures.

Time to make some graphics, so switch to a workspace with ctrl-1:

  1. A new procedure to draw a cube.
  2. Calling this every frame.
  3. Mouse camera controls, move around the cube.
  4. Different built in shapes, drawing a sphere, cylinder, torus.

Then dive into changing the graphics state, so:

  1. Colours.
  2. Transforms.
  3. Textures.
  4. Multiple objects, graphics state persistent like changing a “pen colour”.
  5. Transform state is applicative (scale multiplies etc).

Then tackle recursion, in order to reduce the size of the code, and make much more complex objects possible.

  1. A row of cubes.
  2. Make it bend with small rotation.
  3. Animation with (time).

At this point they know enough to be able play with what they’ve learnt for a while, making procedural patterns and animated shapes.

After this it’s quite easy to explain how to add another call to create tree recursion, and scope state using (with-state) and it all goes fractal crazy.

This is generally enough for a 2 hour taster workshop. If there is more time, then I go into the scene graph and explain how primitives are built from points, faces and show how texture coords work etc. Also the physics system is great to show as it’s simple to get very different kinds of results.

Planet Fluxus

Fluxus now runs in a browser using WebGL. Not much is working yet – (draw-cube), basic transforms, colours and textures. I’ve also built a small site in django so people can share (or perhaps more likely, corrupt) each other’s scripts. Also much inspired by seeing a load of great live coding at the algoraves by Davide Della Casa and Guy John using livecodelab.

fluxuswebgl2

fluxuswebgl

This is a spin off from the work I did a few weeks ago on a silly Scheme to Javascript compiler. It’s still pretty silly, but in order to explain better, first we take a scheme program like this:

;; a tree
(define (render n)
    (when (not (zero? n))
        (translate (vector 0 1 0))
        (with-state
            (scale (vector 0.1 1 0.1))
            (draw-cube))
        (scale (vector 0.8 0.8 0.8))
        (with-state
            (rotate (vector 0 0 25))
            (render (- n 1)))
        (with-state
            (rotate (vector 0 0 -25))
            (render (- n 1)))))

(every-frame 
    (with-state
        (translate (vector 0 -3 0))
        (render 8)))

Then parse it straight into JSON, so lists become Javascript arrays and everything else is a string, also doing minor things like switching “-” to “_”:

[["define",["render","n"],
    ["when",["not",["zero_q","n"]],
        ["translate",["vector","0","1","0"]],
        ["with_state",
            ["scale",["vector","0.1","1","0.1"]],
            ["draw_cube"]],
        ["scale",["vector","0.8","0.8","0.8"]],
        ["with_state",
            ["rotate",["vector","0","0","25"]],
            ["render",["-","n","1"]]],
        ["with_state",
            ["rotate",["vector","0","0","-25"]],
            ["render",["-","n","1"]]]]],

["every_frame",
    ["with_state",
    ["translate",["vector","0","-3","0"]],
    ["render","8"]]]]

Next we do some syntax expansion, so functions become full lambda definitions, and custom fluxus syntax forms like (with-state) get turned into lets and begins wrapped with state (push) and (pop). These transformations are actually written in Scheme (not quite as define-macros yet), and are compiled at an earlier stage. It now starts to increase in size:

[["define","render",
    ["lambda",["n"],
        ["when",["not",["zero_q","n"]],
            ["translate",["vector","0","1","0"]],
            ["begin",
                ["push"],
                ["let",[["r",["begin",
                        ["scale",["vector","0.1","1","0.1"]],
                        ["draw_cube"]]]],
                    ["pop"],"r"]],
            ["scale",["vector","0.8","0.8","0.8"]],
            ["begin",
                ["push"],
                ["let",[["r",["begin",
                        ["rotate",["vector","0","0","25"]],
                        ["render",["-","n","1"]]]]],
                    ["pop"],"r"]],
            ["begin",
                ["push"],
                ["let",[["r",["begin",
                        ["rotate",["vector","0","0","-25"]],
                        ["render",["-","n","1"]]]]],
                ["pop"],"r"]]]]],

["every_frame_impl",
    ["lambda",[],
        [["begin",
            ["push"],
            ["let",[["r",["begin",
                    ["translate",["vector","0","-3","0"]],
                    ["render","8"]]]],
            ["pop"],"r"]]]]]

Then, finally, we convert this into a bunch of Javascript closures. It’s pretty hard to unpick what’s going on at this point, I’m sure there is quite a bit of optimisation possible, though it does seem to work quite well:

var render = function (n) {
    if (!(zero_q(n))) {
        return (function () {
            translate(vector(0,1,0));
            (function () {
                push()
                return (function (r) {
                    pop()
                    return r
                }((function () {
                    scale(vector(0.1,1,0.1))
                    return draw_cube()
                })()))})();
        scale(vector(0.8,0.8,0.8));
        (function () {
            push()
            return (function (r) {
                pop()
                return r
            }((function () {
                rotate(vector(0,0,25))
                return render((n - 1))
            })()))})()
        return (function () {
            push()
            return (function (r) {
                pop()
                return r
            }((function () {
                rotate(vector(0,0,-25))
                return render((n - 1))
            })()))})()})()}};

every_frame_impl(function () {
    return (function () {
        push()
        return (function (r) {
            pop()
            return r
        }((function () {
            translate(vector(0,-3,0))
            return render(8)
        })()))})()})

Then all that’s needed are definitions for all the fluxus 3D graphics calls – the great thing is that these are also written in Scheme, right down to the low level WebGL stuff, so the only Javascript code needed is half of the compiler (eventually this also can be replaced). I was quite surprised at how easy this is, although it is greatly helped by the similarity of the two languages.

Fluxus at Falmouth University

On Friday Cornwall Locative Arts Network, Cornwall Creative Skills and I took over The Academy for Innovation & Research at Falmouth University with a Fluxus workshop, teaching creative coding via recursive procedural 3D modelling for people new to programming. The thing I like most about Scheme as a programming language is that you can very quickly cover the fundamentals of programming (naming values and processes, recursion, and scope) in a 2 hour course with very little time spent on learning syntax or other fiddly things. We had a great spread of attendants, from local artists and designers to lecturers and PhD students, everyone ending up with their own animated procedural shapes.

IMG_20130531_144314

This was followed by the Cornwall Locative Arts Network meeting at which I presented with Tom Goskar, a digital archaeologist, who uses 3D graphics in fascinating ways to read inscriptions and patterns in ancient monuments. I talked about borrowed scenery, doris and sonic bikes and discussed using ushahidi and beagleboards in artistic and scientific projects.

Later on we were invited by Jowan Sebastian Parker to experience Falmouth University’s MakerNow Lab which is opening soon, providing laser cutters, 3D printers and an electronics workshop. I’m hoping to find time to make extensive use of the lab in the not too distant future! The photo above is of their ‘synths on postcards’ example project.