Tag Archives: Livecoding

Picademy Exeter and Future Thinking for Social Living

Last week I had the chance to help out the Raspberry Pi foundation at their Picademy in Exeter. It was good to meet up with Sam Aaron again to talk livecoding on Pis, and also see how they run these events. They are designed for local teachers to get more confident with computers, programming and electronics to the point where they can start designing their own teaching materials on the second day of the two day course. This is a model I’m intending to use for the second inset teacher training day I’m doing next week at Truro school – it’s pretty exciting to see the ideas that they have for activities for their pupils, and a good challenge to help find ways to bring them into existence in a day.


We also had the ending of Future Thinking for Social Living at the Miners Court summer party last week. We exhibited the map made during the workshops, made lots of tea, and had some fun with the pattern matrix in musical mode out in the garden – I adapted Alex’s music system we used with Ellen in Munich to run on Raspberry Pi so it didn’t require a laptop, or a screen at all – simply a speaker. It was interesting how quickly people got the idea, in many ways music is easier to explain than weaving as listening while coding is multi-sensory.


Livecoding UAVs for environmental research

Some screenshots of the UAV livecoding visual programming language. Weather being on our side, we’re planning some test flights later this week! The first program uses GPS to take photos with an overlap of 50% at 300 metres altitude, based on the vertical camera angle as reported from the device. It assumes the the flight orientation is level:


The blocks are all drag and drop and get converted into Scheme code which is run by a modified tinyscheme interpreter. The code can be saved and loaded, and I’m planning to make it possible for people to share code via email.
This is a simpler program which takes a photo every 3 seconds and records a handful of sensor data to the database:


At the bottom you can see a squashed camera preview – I’ve tried various approaches (hiding, scaling to 0 pixels etc) but android requires that there is a preview somewhere in order to take a photo properly. You can view the recorded data on the device too, for checking. There is also a ‘flight mode’ which locks and turns off the screen, and ignores all button events. On some phones you need to take out the battery to stop the program running but unfortunately on others you can still use the power button to close the program.


Coding with threads: Frame loom

After writing the 4 shaft loom simulation the next job was to try weaving the structures with real threads. Would I be able to replicate the predicted patterns and structures? Ellen warned me that the meander weave would result in unstable fabric, but it would depend on the nature of the material used so was worth trying. Originally I planned to warp up the Harris loom but I need to work up to that as it’s a big and complex job, so I quickly built a frame loom with some bits of wood and nails at 5mm intervals to hold the warp in place.

A simple frame loom

Here you can see it set up with the all important first ‘shed’ (name given to the gap between subsets of warp theads), which defines the order of the threads. I packed the warp too tightly and messily so this was important – luckily as the yarn colours alternate so it made it easy to make.

'sleying' the warp

Here I’m sleying the shafts using threads to pick up the warp as defined by the simulation toggle buttons. The threads (which form heddles) are tied on to wooden poles which are pulled in different combinations during weaving. This is the approach we saw on the warp weighted looms in Copenhagen, I’m not sure if it’s usually used on frame looms – it was cumbersome but much faster than counting threads manually each time. It’s important to use thinner threads than the warp, but you need to put quite a bit of tension on them so they need to be strong. There is something very appropriate in the context of this project about coding threads with threads in this way.

Four shafts set up ready to start

Here it is finished and ready to start weaving. I numbered the shafts with pencil but it’s actually very obvious based on the order they are attached so I never used them. Following the lift plan from the simulation was quite easy, thinking about the pattern more than the combinations of numbers – as I went on I could tell where I was based on the nature of the shed, keeping an eye on the rhythm of the warp threads picked up. Also the parts where I need to lift 3 and leave 1 was really tricky – not helped by the fact that the resulting weft was difficult to see at that point.

Picking up shaft 4

In relation to livecoding, I was surprised to the extent that improvisation is required when weaving even based on a predefined pattern. There is a lot of reasoning required in response to issues of structure that cannot be defined ahead of time. You need to respond to the interactions of the materials and the loom itself, the most obvious problem you need to think about and solve ‘live’ is the selvedge – the edges of the fabric. In order to keep the weave from falling apart you need to ‘tweak’ the first and last warp thread based on which weft yarn colour thread you are using. The different weft threads also need to go over/under each other in a suitable manner which interacts with this. This will be important to include in the simulation properly, but this will only give an early indication of problematic decisions, rather than a failsafe solution.

Meander closeup

Here’s a closeup of the meander pattern compared to the simulation. The yarn is cheap and a bit fuzzy, but hopefully you can see the structure – the differences are interesting. I’m not sure how this will distort further when I remove it from the loom and the tension is gone.

Freestyle patterns

Here are some more freestyle patterns, the boxy ones turned out to be more stable than the meanders – it’s really satisfying to see them emerge from the abstract set of rules that you work with to lift the shafts, not unlike graphics programming. Which of the 4 shafts to lift can be thought of like 4 bit opcodes with different ordering resulting in indirect pattern shifts.

There are three types of limitation that I’d like to note and think about (especially in terms of incorporating them in a programming language). One is the selvedge, as I mentioned earlier – another is floats, which cause the problems on the meander pattern (long threads not incorporated into the fabric). The third is more subtle, some sequences of sheds cause problems when packing down the weft, for example if you are not too careful you can cause the ordering of the weft colours to be disrupted in some situations.

Unravelling technology in Copenhagen

Last week the weavingcodes/codingweaves project started with a trip to Denmark, our first stop was the Centre for Textiles Research in Copenhagen where we presented the project and gathered as much feedback as possible right at the beginning. The CTR was introduced to us by Eva Andersson Strand, and is an interdisciplinary centre which focuses on the relationships between textiles, environment and society.


This long-view perspective of technology is critical for us, as we are dealing with a combination of thinking in the moment via livecoding and a history of technology dating back to the neolithic. This is a warp weighted loom, the focus of much of Ellen Harlizius-Klück’s research and the technology we are going to be using for the project.


Weights like this are widespread in the archaeological record for many cultures around the world, with the earliest ones around 5000 BC. Similarly – a post-it note including a handy cuneiform translation:


Alex talked about livecoding as a backwards step, removing the interface – thinking about it as an unravelling of technology. His introduction to Algorave led to many connections later when Giovanni Fanfani described the abstract rhythmic patterns of Homeric rhapsodic poetry. These were performed by citizens, in a collaborative and somewhat improvised manner – the structures they form musically and in language are potentially of interest as they seem to echo the logic of weaving pattern.


Ellen described her research into tacit knowledge of ancient Greek society – how weaving provided thinking styles and ordering concepts for the earliest forms of mathematics and science which is the basis for much of the weavingcodes project. One additional theme that has come up fairly consistently is cryptography – Flavia Carraro’s description of ‘The Grid in the decipherment of the Linear B writing system: a “paper-­‐loom”?’ was another addition to this area.

Emma Cocker talked about Peneolopeian time – constant weaving and unravelling as a subversive act, and the concept of the kairos, as a timely action – the name given to the point at which the weft is made when the warp ‘shed’ is provided, as well as a part of the warp weighted loom. Her input was to provide a broader view to our explorations (as coders, weavers and archaeologists all tend to get caught up in technical minutiae from time to time). From our discussions it was apparent that one of the strongest connections between livecoding and ‘weaving as thought’ is a subversion of a form of work that is considered by the dominant culture as entirely utilitarian.

Thinking outside of the screen (#1)

I’m starting a new exploratory project to build a screen-less programming language based on two needs:

  • A difficulty with teaching kids programming in my CodeClub where they become lost ‘in the screen’. It’s a challenge (for any of us really but for children particularly) to disengage and think differently – e.g. to draw a diagram to work something out or work as part of a team.
  • A problem with performing livecoding where a screen represents a spectacle, or even worse – a ‘school blackboard’ that as an audience we expect ourselves to have to understand.

I’ve mentioned this recently to a few people and it seems to resonate, particularly in regard to a certain mismatch of children’s ability to manipulate physical objects against their fluid touchscreen usage. So, with my mind on the ‘pictures under glass’ rant and taking betablocker as a starting point (and weaving code as one additional project this might link with), I’m building some prototype hardware to provide the Raspberry Pi with a kind of external physical memory that could comprise symbols made from carved wood or 3D printed shapes – while still describing the behaviour of real software. I also want to avoid computer vision for a more understandable ‘pluggable’ approach with less slightly faulty ‘magic’ going on.

Before getting too theoretical I wanted to build some stuff – a flexible prototype for figuring out what this sort of programming could be. The Raspberry Pi has 17 configurable I/O pins on it’s GPIO interface, so I can use 5 of them as an address lookup (for 32 memory locations to start with, expandable later) and 8 bits as input for code or data values at these locations.

The smart thing would be to use objects that identify themselves with a signal, using serial communication down a single wire with a standard protocol. The problem with this is that it would make potential ‘symbol objects’ themselves fairly complicated and costly – and I’d like to make it easy and cheap to make loads of them. For this reason I’m starting with a parallel approach where I can just solder across pins on a plug to form a simple 8 bit ID, and restrict the complexity to the reading hardware.

Testing the 74HC4067 16-channel analog mult iplexer/demultiplexer
Testing the 74HC4067 16-channel multiplexer/demultiplexer

I’ve got hold of a bunch of 74HC4067 multiplexers which allow you to select one signal from 16 inputs (or the other way around), using 4 bits – and stacking them up, one for each 8 bits X 16 memory locations. This was the furthest I could go without surface mount ICs (well out of my wonky soldering abilities).

Building the board, (with narrow 24 pin IC holders sliced down the middle). The input comes in via a common bus down the centre of the board.
Building the board, (with narrow IC holders hacked by slicing them down the middle). The input comes in via a common bus down the centre of the board.
Solder practice
Solder practice
Testing the first 4 bits on the breadboard
Testing the first 4 bits on the breadboard

Now 4 bits are working it’s harder to test with an LED – so next up is getting the Raspberry Pi attached.

Many languages: Düsseldorf Institute for Music and Media Seminar

Last week was my first official seminar at the Düsseldorf Institute for Music and Media with Julian Rohrhuber filling my new role as Associate Professor in Critical Programming. I wanted to start by introducing the cultures and history of programming, with a focus on the people who invented programming languages and what they were doing if for – from the early mathematicians to the military/space industry and in more recent times the rise of JavaScript from a language that would only ever be used for “animating buttons” to the language with widest reach.


With that in mind I wanted to try teaching a fluxus workshop using planet fluxus, the version that compiles Scheme to JavaScript rather than the native code version. This is now working in a new url with quite a lot of fixes and now quite a lot of testing carried out on it. I’m pretty pleased with the support for webgl – and plan to use it for some upcoming games, other than needing switching on with some versions of Safari, it otherwise seems pretty widespread and fast.

My second day of teaching was followed by a presentation by Ellen Harlizius-Klück and Alex McLean on weaving, ancient mathematics, programming, mythology and music – which provided a great introduction for a meeting we had the next day on an upcoming project bringing these concepts together.


slub at Kunsthal Aarhus

Last week Alex and I took to the road on another slub mini-tour starting in Denmark at the Kunsthal Aarhus where we ran a livecoding workshop and performed at the opening of the Aarhus Filmfestival.



The Kunsthal gallery was exhbiting “Systemics #2: As we may think (or, the next world library)” with work by Florian Hecker, Linda Hilfling, Jakob Jakobsen, Suzanne Treister, Ubermorgen, YoHa + Matthew Fuller.

Linda Hilfling and UBERMORGEN’s work comprised an Amazon print on demand hack which was perhaps an even more elaborate version of their previous Google Will Eat Itself. The gallery floor was printed with a schematic describing the processing from the raw material input to the finished printed books.


Suzanne Treister’s work called HEXEN 2.0 included alternative/hidden histories of technology presented as densely descriptive tarot cards and prints showing many connections between individuals, events and inventions.