Livecoding – Page 15 – dave's blog of art and programming

Traffic test

I’ve added some placeholder building models, and a bit of traffic. No animation, just getting the logic right – follow the roads and don’t double back.

Fluxus Friday: Procedural city

Started working on a new idea today.

Thanks to the ever helpful Matthew Flatt, I can now catch scheme errors before they cause an exception and stop everything running. It’s also possible to detect that an error has occurred and do something else (play a suitable sample, electrify the keyboard…)


(define error-happened #f)

(define (my-error-handler n)
    (set! error-happened #t))

 (with-handlers ([(lambda (x) #t) my-error-handler])
    (modulo 0 1 2)) ; some erroneous code

(when (error-happened)
    (open-trapdoor))

Scheme bricks, menus and mice

The first performance attempt of a livecoding system is always stressful, but scheme bricks at make art was especially so for me – using the trackpoint on my thinkpad hurt my finger, there was too much typing and it generally felt really really hard (I ended up switching to betablocker). In order to help combat this I’ve taken the following measures:

Added a menu with common commands and atoms you can drag and drop

Using a mouse – and employing the wheel for scrolling the menu

Rehersing!

The last point is key really, and I’m having quite a bit of fun with it now, so all going well, I’ll be giving it another go next week.

slub @ noise = noise

Fluxus manual

I spent a lot of the weekend working on improving the fluxus documentation by writing something which might serve as a user manual. Lots of work to do on it yet though.

L system music revisited

I’ve hacked a different way of interpreting l systems which is more suited to time based patterns, such as for music. Instead of parsing the rules into a long string in one go (as I used to do for pattern cascade), this version uses a stack based method to evaluate them continuously, meaning that they use up much less memory and the processing time is spread out – this means you can set the recursion depth much higher, or should that be deeper? The code is here.

Here’s an example run, although be warned that the synth patches I’m using are rather untamed (partly due to the mood I was in when composing 🙂

The rules for this are:

cCBca-aa/c-d-c<.d/b++b+ACd

Which I think is quite a good compression ratio for the complexity resulting - this is an important aspect of the 'livecode-ability' of a procedural approach, less keystrokes equals more time to think about what you are doing. If the embedded thing doesn't work, the archive.org page is here