Life on an Algorave Tour

Some pictures taken during the recent Algorave Tour, making people dance to algorithms in Brighton, London, Karlesruhe, Cologne and Dusseldorf.

The MS Stubnitz moored in Canary Wharf surrounded by financial architecture:
IMG_20130418_135658

IMG_20130418_140810

Wandering around during soundcheck, a heavy duty workshop on the Stubnitz:
IMG_20130418_143850

Sound checking with Andrew Sorenson:
IMG_20130418_162540

A speaker close up, one of many:
IMG_20130418_162740

Norah Lorway shaking the boat’s superstructure with sub bass:
IMG_20130418_200317

MYK livecoded acid squelch:
IMG_20130418_204823

Sick Lincoln deploying highly danceable crowd pleasing algorithms:
IMG_20130418_213634

Mico Rex, Mexico’s finest algorave pop duo closing the night:
IMG_20130418_222153

Onward to Karleruhe, a random photo of the slub soundcheck:
IMG_20130420_080039

Hernani Villaseñor 8bit house with visible parentheses:
IMG_20130420_082809

Fredrik Olofsson livecoding 5 arduino’s simultaneously for 2 bit grindcore:
IMG_20130420_111707

Random notes from the Live Code Festival, Karlsruhe

During his talk at the live code festival Karlsruhe 2013, David Ogborn (to paraphrase from my faulty memory) said that livecoding seems a very current thing, that something about it seems to be in the air, so much of what we are doing seems to stick and thrive like a form of bacteria.

fofofo
Yorgos Diapoulis talking about his minimal interface for live hardware coding.

This festival made it obvious that communities surrounding livecoding are thriving, with representation from Australia, Mexico and Canada as well as European regions and accordingly a wild variety of approaches, techniques and styles that now make up livecoding. The symposium was fundamentally a celebration of this and a chance to experience the diversity directly.

From my scrappy notes and in no particular order, Andrew Brown focused on a describing livecoding technique as an interplay between ‘complexity and succinctness’ in the context of musical research involving data mining large quantities of musical material. Here, as in many issues of creativity in livecoding, the critical decision is where to abstract away details in order to provide a usable and flexible creative environment. His approach is to look for patterns in musical data in order to provide a ground truth, and then make subjective decisions based on practice and performance to build a livecoding interface. Andrew mapped out other useful dichotomies we battle with such as the tension between modelling and simulations of creative understanding vs inspiration, which can come from many places.

IMG_20130420_031441
A rare appearance of Click Nilson (the British tabloid press was unfair to him.)

Catching up with the rapid development of the phenomenon that is Benoit and the Mandelbrots, their side project “Delbots and the man” is a doomcore livecoding band involving a live drummer – a promising new sonic direction for livecoding. Also on a more technical level their drop function provides a means to allow code to be executed simultaneously in all performers machines, used as a way to accelerate or amplify ‘from scratch’ livecoding techniques in groups.

Propelling livecoding into the chaotic world of web development, Chad McKinney‘s project Lich.js is a new general purpose programming language for browser based livecoding, built on top of javascript. The recent explosion of programming languages based on/built with javascript is due to the fact that it’s interpreter is available everywhere, and this will be (IMHO) increasingly be where livecoding happens in the future.

IMG_20130420_131232
Section 9 live coded both progressive and recursive house, simultaneously.

In contrast, Andrew Sorenson demonstrated the potential to provide liveness and ‘hot swapping’ of code down to the lowest computing levels with Extempore, which can now run on a large number of architectures and levels of concurrency, and now generates code approaching the efficiency of C compilation in many situations.

More reports on the festival, and associated Algorave events to follow.

Fluxus workshop in Falmouth

After rushing around Europe doing a lot of livecoding over the last week (more on that soon) I’m really pleased to announce this workshop closer to home in Falmouth:

CLAN and CREATIVE SKILLS present: CREATIVE CODING taster session for ABSOLUTE BEGINNERS with Dave Griffiths

Friday May 31st 10.30am – 12.30pm
AIR building, Falmouth University, Tremough Campus TR10 9EZ
Places: For 10 people only

Deposit: There are limited places so you will need to pay a £15 deposit to secure your place when you book, which will be refunded before the workshop. If you don’t turn up you lose your deposit. To book: Please email: admin@creativeskills.org.uk

In this workshop for beginners with award winning game designer, creative coder and live coding artist Dave Griffiths you will find out about the emerging art form of live coding and learn how to write simple programmes to create animations in 3D space. You will be introduced to fluxus, an open source game engine for live coding worlds into existence, used by artists, performers and digital practitioners for installations, VJing, games and education.

What will you do? What will you achieve?

You will create 3D animated forms, and have an introduction to fundamental programming concepts, naming of values and processes, recursion and digital representation of colour, 3D shape and texture.

There will be coffees and teas.

At 1pm Dave will talk at a free event-

CLAN – Cornwall Locative/ Interactive Arts Network

1-2pm AIR Sandpit

Speakers: creative coder Dave Griffiths is joined by digital archaeologist Tom Goskar.

New Portuguese Bicycle Operatics

Prepare your bicycle clips! Kaffe Matthews and I are starting work on a new Bicycle Opera piece for the city of Porto, I’m working on a new mapping tool and adding some new zone types to the audio system.

While working on a BeagleBoard from one of the bikes used in the Ghent installation of ‘The swamp that was…’, I found (in true Apple/Google style) 4Mb of GPS logs, taken every 10 seconds during the 2 month festival that I forgot to turn off. Being part of a public installation (and therefore reasonably anonymised 🙂 – this is the first 5th of the data, and about all it was possible to plot in high resolution on an online map:

It’s interesting to see the variability of the precision, as well as being able to identify locations and structures that break up the signal (such as the part underneath a large road bridge).

Al Jazari – ambient occlusion

A big part of the look of Minecraft comes from it’s Smooth lighting, which includes an illumination model called ambient occlusion. Ambient occlusion darkens areas of an object based on how obscured they are from a wide area light source, for example an entire sky area, as opposed to a point light source. This is often complicated to calculate in realtime, but with simplified geometric voxels it’s fairly fast to do, building on the code from the hollowing out optimisation I mentioned previously. For each point on a cube’s corners you can add up it’s surrounding empty cubes – the more empty space in the 8 voxels, the brighter the corner needs to be. In this way, we are assuming light is coming from all directions (hence ambient) and don’t need to take into account positions of lights etc.

occ

Here is the raw ambient occlusion lighting in Al Jazari 2, rendered as unlit vertex colours on each visible cube:

aj2-2

Then we add standard direct lighting to the ambient occlusion:

aj2-3

And here is the final image with textures added:

aj2-4

There are a few artefacts in the lighting due to the cubes not all being the same size (in order to minimise the complexity of what is drawn), here is the world coloured based on the size of the octree leaf node – the brighter blue areas are bigger cubes:

aj2-1

Once the ambient occlusion is calculated we only need to recalculate it when surrounding voxels are changed. In practice the splitting/joining of the octree levels when blocks are created and destroyed seems to take care of this in most cases.

;; returns a list of samples to test
(define (occ-samples pos) 
    (list 
     (vadd pos (vector  -1 -1 -1))
     (vadd pos (vector  -1 -1  0))
     (vadd pos (vector  -1  0 -1))
     (vadd pos (vector  -1  0  0))
     (vadd pos (vector   0 -1 -1))
     (vadd pos (vector   0 -1  0))
     (vadd pos (vector   0  0 -1))
     (vadd pos (vector   0  0  0))))

;; count up the empty voxels and calculate occlusion value
(define (calc-occlusion o pos)
  (let* ((samples (occ-samples pos))
         (coverage (/ (foldl
                       (lambda (p r)
                         (+ (if (octree-leaf-empty? (octree-ref o p)) 1 0) r))
                       0
                       samples)
                     (length samples))))
    (min 1 (* 2 coverage))))

;; helper to set a bunch of verts in one go
(define (pdata-list-set! k l v)
  (for-each (lambda (i) (pdata-set! k i v)) l))

...

;; uses the cube's position and size to set the vertex colour on each corner
(with-primitive my-cube
  (translate pos)
  (pdata-list-set! "c" '(3 7 19) (calc-occlusion o (vadd pos (vector 0 0 0))))
  (pdata-list-set! "c" '(10 14 21) (calc-occlusion o (vadd pos (vector size size size))))
  (pdata-list-set! "c" '(2 4 23) (calc-occlusion o (vadd pos (vector size 0 0))))
  (pdata-list-set! "c" '(9 15 17) (calc-occlusion o (vadd pos (vector 0 size size))))
  (pdata-list-set! "c" '(0 8 18) (calc-occlusion o (vadd pos (vector 0 size 0))))
  (pdata-list-set! "c" '(5 13 22) (calc-occlusion o (vadd pos (vector size 0 size))))
  (pdata-list-set! "c" '(6 12 16) (calc-occlusion o (vadd pos (vector 0 0 size))))
  (pdata-list-set! "c" '(1 11 20) (calc-occlusion o (vadd pos (vector size size 0)))))

Al Jazari – scooping out the insides of planets with scheme

Optimisation is a game where you write more code in order to do less. In Al Jazari 2 doing less means drawing less blocks. Contiguous blocks of the same type are already automatically collapsed into single larger ones with the Octree – but if we can figure out which blocks are completely surrounded by other blocks, we can save more time by not building or drawing them either.

Here is a large sphere – clipped by the world volume, showing a slice through the internal block structure:

aj2-skin1

The next version has all internal blocks removed, in this case shaving 10% off the total primitives built and drawn:

aj2-skin2

The gaps in the sphere from the clipping allow us to look inside at how the octree has optimised the structure. The gain is higher in a more normal Minecraft set up with a reasonably flat floor covering a large amount of blocks. Here is the code involved, built on top of a functional library I’m building up on to manipulate this kind of data. It maps over each Octree leaf checking all the blocks it touches on each of its six sides, taking into account that the size of the leaf block may be bigger than one.

(define (octree-check-edge f o pos size)
  (define (do-x x y)
    (cond
     ((eq? x -1) #f)
     ((octree-leaf-empty? (octree-ref o (vadd pos (f x y)))) #t)
     (else (do-x (- x 1) y))))
  (define (do-y y)
    (cond
     ((eq? y -1) #f)
     ((do-x size y) #t)
     (else (do-y (- y 1)))))
  (do-y size))

(define (octree-is-visible? o pos size)
  (or
   (octree-check-edge (lambda (x y) (vector size x y)) o pos size)
   (octree-check-edge (lambda (x y) (vector -1 x y)) o pos size)
   (octree-check-edge (lambda (x y) (vector x size y)) o pos size)
   (octree-check-edge (lambda (x y) (vector x -1 y)) o pos size)
   (octree-check-edge (lambda (x y) (vector x y size)) o pos size)
   (octree-check-edge (lambda (x y) (vector x y -1)) o pos size)))

(define (octree-calc-viz o)
  (octree-map
   (lambda (v pos size depth)
     (octree-leaf
      (octree-is-visible?
       o pos size)
      (octree-leaf-value v)))
     o))