Tag: scheme bricks

Algorave practice

It’s been a huge amount of time since I recorded anything, but I thought I would a) try and do some actual livecoding practice for the upcoming algorave on Thursday and b) record everything. As usual I’m following my foolhardy approach of improvising both musical structure and sound material by livecoding synth graphs from scratch. Sometimes it takes while longer than I would like to reach a suitable musical complexity (this is faster in a real live situation, with increased adrenaline), and some fiddly things there never seems time to sort out, such as stereo! For these recordings, and live on stage with slub I use the scheme bricks visual programming language. Here are some of my favourites, the complete set is here.

Al Jazari 2 – minecraft meets fluxus

Some screenshots of the in-progress next generation Al Jazari livecoding world. This is a voxel rendered world, inspired in part by Minecraft but with an emphasis on coding robots in scheme bricks who construct artefacts from the materials around them. The robot language is still to be designed, but will probably resemble Scratch.

aj2-002

You can ‘jump on board’ the different robots (cycling through them with ‘space’) and program them with commands which include picking up or dropping individual blocks. The program above allows you to control the robot with the ‘w’, ‘a’, ‘s’, ‘d’ keys with ‘z’ to tunnel downwards, and ‘x’ to remove the block in front of the robot.

aj2-001

The world is built quite simply from an octree – which provides an optimised structure for rendering the 64x64x64 level cube in realtime. The view below shows the compression – large areas containing the same material (or empty space) can be represented by leaf nodes terminating the tree early without needing to store each of the 262,144 1x1x1 cubes. After each edit, the octree may fragment or collapse it’s tree (via setting new values in 3D space or a ‘compress’ operation). The scheme code can be found here.

aj2-003

slub at /* vivo */

My last /* vivo */ Mexico post, some data from our livecoding performance on the final day. This was one of those performances where we had a rough plan and got a bit too carried away by the crowd to follow it (I guess one of the great things about improvisation!). Also to a great deal the music was influenced by mezcal, the fermented spirit from the maguey plant, which I can report is the secret ingredient of Mexican livecoding. My edit history and a screen shot of the final state of the program is online here. The new temporal recursion system was actually pretty damn challenging (hence the serious face) but in combination with Alex’s pattern generation seemed to get people moving pretty well…

scheme bricks 2

A new version of scheme bricks is under way, planned to be tested out with slub on the Mozilla Fest Party, then taken across the Atlantic for some more livecoding action in Mexico City! New things include blocks with depth – cosmetic for the moment, but I plan to prototype some new ideas based on this, separately zoom-able code blocks, and most importantly it’s a complete rewrite into functional R5RS Scheme for portability – it should now be relatively simple to get it on android via Nomadic which uses Tinyscheme.

Using the new temporal recursion, the code produced is much less monolithic. Massively tall structures resulting from plugging together sequences during long performances were a bit of an issue before, but splitting the code into a multitude of functions (which can be shrunk and put in the “background”) seems to be a far easier way of working so far.

Temporal recursion

Slub have a number of important livecoding transmissions coming up (including a performance at the Mozilla Festival!) so it’s time to work on fluxus/fluxa/scheme bricks. Here are some recording tests of a feature I’ve been wanting to use for a long time – temporal recursion.

These recordings were not changed by hand as they played, but started and left running in ‘generative audio’ mode in order to try and understand the technique. This method of sequencing is inspired by Impromptu which uses a similar idea. In fluxa it’s all based around a single new function: “in” which schedules a call to a function – which can be the current function (this is different to the existing ‘timed tasks’ in fluxus which are less precise for this kind of sequencing). 

(define (tick time a)
    (play (+ time 3) (sample "ga.wav" (note (pick '(40 42 45) a))))
    (in time 0.22 tick (+ a 1)))

(in (time-now) 1 tick 0)

The “in” function takes the current time, the time to wait before the call, the function to call and it’s parameters. In the example above the argument “a” gets incremented each time, resulting in a sequence of notes being played. Recursion generally brings up thoughts of self similarity and fractal patterns – as in the graphical use of recursion in fluxus, but here it’s better to imagine a graph of function calls. Each function can branch to a arbitrary number of others, so limitations have to be put in place to stop the thing exploding with too many concurrent calls. What seems to happen (even with small function call graphs) is the appearance of high level time structures – state changes and shifts into different modes where different patterns of calls lock into sequence. You can hear this clearly in the second recording above which alters itself half way through.

I’ve also experimented with visualising the call graph, with limited success with this more complex example – the round nodes are functions, the boxes parameter changes and labels on the connections are the branch conditions:

(require fluxus-018/fluxa)

(searchpath "/home/dave/noiz/nm/")
(define n '(23 30))
(set-scale '(1 1 2 1))

(define (za time a b)
    (play (+ time 3) (mul (mul (adsr 0 0.1 1 1) (pick '(0.4 0.1 1 0.4 1) a)) 
        (sample "ga.wav" (note (- (modulo (- b a) 17) (* (pick n a) 2))))) -0.5)
    (when (zero? (modulo a 16)) (in time 0.3 zm a b))
    (if (eq? (modulo a 14) 12)
        (in time 1.0 zoom a (- b 1))
        (in time (- 0.5 (* (modulo a 13) 0.03)) za (+ a 1) (+ b 2))))

(define (zm time a b)
    (play (+ time 3) (mul (mul (adsr 0 0.1 1 1) (pick '(0.1 0.4 1) a))
        (sample "ga.wav" (note (+ (modulo b 5) (/ (pick n a) 2))))) 0.5)
    (if (> a 12)
        (in time 1.0 za b a)
        (in time (pick '(1.3 1.5 0.5) a) zm (+ a 1) b)))

(define (zoom time a b)
    (play (+ time 3) (mul (mul (adsr 0 0.1 1 1) (pick '(0.1 0.2 0.3) a)) 
        (sample "ga.wav" (note (+ (pick n a) (* 3 (modulo a (+ 1 (modulo b 5)))))))))
    (if (> a 16) 
        (in time 0.3 zm 0 (+ b 1))
        (in time (pick '(1.3 0.12) a) zoom (+ a 1) b)))

(in (time-now) 1 zoom 0 1)

Cyclic score sketching for livecoding

Live coding in cyclic time, while making the process of sketching, painting and general mark making as much part of the musical performance as the coding is. This is a prototype for “The Hair of the Horse”, a performance with Alex McLean and Hester Reeve as part of Live Notation at the Arnofini on Friday 27th July. It’s incomplete without Alex’s code over projected and I’m also expecting the performance will consist of a much larger and messier score!

Truffle Blocks

A new project running here that brings together Germination X’s HTML5 game engine with Google’s Blockly in the spirit of Fluxus and particularly Scheme Bricks.

I’ve had a plan for working on a visual programming language for browser based games (and got someway to implementing Scheme Bricks with the Naked on Pluto art installation). Blockly has saved me a lot of time, and is inspired in turn by Scratch from MIT and it has some really nice additional tricks – like being able to add comments and collapse blocks. This is approaching the way I’d really like to be able to program these kinds of games, in terms of rapid prototyping but also one day perhaps full development.

Truffle Blocks is only a few days old and very proof of concept at the moment – the underlying game engine still needs a lot of work as it’s a port from the HaXE/flash version, and although it’s not been designed for this kind of programming it was pretty fast to get something fairly usable running.

Blockly is quite different from Scheme Bricks – which is very freeform but requires you to remember how the syntax works to build up more complex forms (as in Lispy dialects generally). Scratch and Blockly build a lot of this syntax information into the structure of their blocks, making it great for teaching programming. One of the things about Blockly which is going to be useful is the ability to modify blocks themselves in a similar editor – for example this screenshot of modifying the if block to include arbitrary numbers of elseif and a final else section:

All the source is hosted on gitorious here.