Coding with threads: Tablet loom

Tablet weaving is an ancient form of pattern production using cards which are rotated to provide different sheds between warp threads. It’s used to produce long strips of fabric, or the starting bands and borders that form part of a larger warp weighted weaving. We’ll come to the second use later in the weaving codes project.

Tablet weaving

There are quite a few programs around to simulate the tablet weaving process – I used this program to get an initial understanding, here’s an example screenshot:


When using square cards the convention is to name the holes a,b,c,d in clockwise order from the top left corner. The thread that is facing, so creating the colour is shown on the left. This program allows you to choose forward or back 90 degrees at a time for all the cards (the up/down arrows on the right) as well as flipping individual cards (the list of / and \ at the bottom).

To start with I decided to try a double faced weave, using two colours. There is a good site that describes tablet weaving here. I chose this kind of setup as it’s possible to create the warp using 4 continuous threads making it quite fast to get started.

Warping a double faced weave

The best weaving technique I found was to attach one end of the warp to a fixed object behind me and the other to a piece of wood I use to maintain tension with my feet, and pushing the weft threads away from me.

There are many different ways to manipulate the cards to affect the structure created, most of the time you rotate all the cards 90 degrees either forward or back between each weft. There is a limit to how far you can go in one direction before the warp behind the cards gradually gets tangled up, so you need to maintain a balance. You can also flip them so they change direction in respect to the others and also the warp becomes twisted differently which affects the pattern. You can also rotate the cards forward and back individually too, although this doesn’t seem to be used much.

Here is a section of the tablet weaving I managed to produce, both sides are shown:


Section A was an attempt at direct pattern control, all the cards are matched up in terms of rotation, but I’m using flipping to change the ‘facing’ colour one by one to manually create a diagonal line. The process I was following consisted of turning forward 90 degrees, one weft, back 90 degrees one weft, then flip the individual cards and repeat. This unfortunately results in a bad structure with long floats.

In section B I tried going forward one more turn before going back two. It took me a while to work this out as it means the same shed (and card configuration) actually creates different colours based on what you did in the previous step – this weaving has a memory! I need to look closer at the structure, or perhaps set up a huge tablet weaving with rope to figure out exactly what is happening here. This structure works much better than A, but notice the jagged edges on part of the diagonal – this is because the pattern is going against the twist direction of the warp in these sections.

Section C is an indirect pattern technique, and much more satisfying – I changed the relative rotation of the cards at the end of section B, then rotated them all together 90 degrees back and forward throughout section C, the change in the pattern is down to the ‘balance’ of backs to forwards. The ‘memory’ effect smooths the pattern, and it always goes with the warp twist, but notice that with this technique the different sides of the fabric have a different pattern, it’s not the inverse – I’m not clear exactly why this is yet.

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.

Dyadic device: a 4 shaft loom simulation.

On the train back from the Sheffield codingweaves workshops back in October I wrote a quick browser program to attempt to further understand the relationship between structure and pattern in weaving – which I’ve put online here. This works in the inverse of how we’ve been writing weaving simulation programs so far. Instead of defining the pattern you want directly, you are describing the set up of a 4 shaft loom – so the warp threads that each of 4 shafts pick up in the top row of toggle boxes, then which shafts are picked up for each weft thread as the fabric is woven on the right.

This involved writing a program that is based closely on how a loom functions – for example calculating a shed (the gap between ordered warp thread) by folding over each shaft in turn and or-ing each warp thread to calculate which ones are picked up. This really turns out to be the core of the algorithm – here’s a snippet:

;; 'or's two lists together:
;; (list-or (list 0 1 1 0) (list 0 0 1 1)) => (list 0 1 1 1)
(define (list-or a b)
   (lambda (a b)
     (if (or (not (zero? a)) (not (zero? b))) 1 0))
   a b))

;; calculate the shed, given a lift plan position counter
;; shed is 0/1 for each warp thread: up/down
(define (loom-shed l lift-counter)
   (lambda (a b)
     (list-or a b))
   (build-list (length (car (loom-heddles l))) (lambda (a) 0))
   (loom-heddles-raised l lift-counter)))

I’ve become quite obsessed with this program, spending quite a lot of time with it trying to understand how the loom setup corresponds to the patterns. Here are some example weaves that you can try. Colour wise, in all these examples the order is fixed – both the warp and the weft alternate light/dark yarns.


This is tabby or plain weave – the simplest and strongest weave (used for sails and hard wearing fabric). The striped pattern is a result of this alternating colour order.


Basket weave – doubling the plain weave, results in a zigzag pattern.


This is called 2×2 twill, the structure provides a stretchy fabric, often used for clothes. Notice that the pattern in the same as the basket weave even though the structure is different – this is a hint at how structure and pattern are linked in strange ways (it gets much more complex than this of course).


I’ve become very interested in this threading pattern for the shafts as it results in lots of interesting patterns. This is an example of connected boxes.


A slight shift and we can obtain meanders, an important motif of the kairotic project. It turns out this is a highly unstable structure due to the length of the ‘floats’ – the threads spending too long without being incorporated back into the weave. More on that later on.


Here’s a more freeform weave where I switch patterns between different types by changing the lift order. Much like music, it’s possible to switch patterns in a nice way that doesn’t interrupt the flow.

Next up is building a real loom to try these patterns out in thread form.

Some algorithms for Wild Cricket Tales

On the Wild Cricket Tales citizen science game, one of the tricky problems is grading player created data in terms of quality. The idea is to get people to help the research by tagging videos to measure behaviour of the insect beasts – but we need to accept that there will be a lot of ‘noise’ in the data, how can we detect this and filter it away? Also it would be great if we can detect and acknowledge players who are successful at hunting out and spotting interesting things, or people who are searching through lots of videos. As we found making the camouflage citizen science games, you don’t need much to grab people’s attention if the subject matter is interesting (which is very much the case with this project), but a high score table seems to help. We can also have one per cricket or burrow so that players can more easily see their progress – the single egglab high score table got very difficult to feature on after a few thousand players or so.

We have two separate but related problems – acknowledging players and filtering the data, so it probably makes sense if they can be linked. A commonly used method, which we did with egglab too (also for example in Google’s reCAPTCHA which is also crowdsourcing text digitisation as a side effect) is to get compare multiple people’s results on the same video, but then we still need to bootstrap the scoring from something, and make sure we acknowledge people who are watching videos no one has seen yet, as this is also important.

Below is a simple naive scoring system for calculating a score simply by quantity of events found on a video – we want to give points for finding some events, but over some limit we don’t want to reward endless clicking. It’s probably better if the score stops at zero rather than going negative as shown here, as games should never really ‘punish’ people like this!


Once we have a bit more data we can start to cluster events to detect if people are agreeing. This can give us some indication of the confidence of the data for a whole video, or a section of it – and it can also be used to figure out a likelihood of an individual event being valid using the sum of neighbouring events weighted by distance via a simple drop-off function.


If we do this for all the player’s events over a single video we can get an indication of how consistent they are with other players. We could also recursively weight this by a player’s historical scores – so ‘trusted’ players could validate new ones – this is probably a bit too far at this point, but it might be an option if we pre-stock some videos with data from the researchers who are trained with what is important to record.

Connecting Flask to Apache

When exploring the cosmos of python powered web frameworks it’s easy to get lost due to fast moving versions. Recently we had a lot of difficulty getting Flask connected via a WSGI script on Apache. This seems to be due to needing the object factory to be called specifically rather than relying on the module namespace to do the work for us, there doesn’t seem to be much help online about this yet. We’re also running python in a virtualenv so the working wsgi script looks like this:

import sys
import logging
import os

PROJECT_DIR = "/var/www/yourflasksite/"
activate_this = os.path.join(PROJECT_DIR, 'bin', '')
execfile(activate_this, dict(__file__=activate_this))

from app import create_app
application=create_app(os.getenv('FLASK_CONFIG') or 'default')
application.secret_key = 'your site's key'

For completeness, here is the apache config that starts it up:

<VirtualHost *:80>
    ServerName your.url
    WSGIScriptAlias / /var/www/yourflasksite/yoursite.wsgi
    <Directory /var/www/yourflasksite/app>
	Order allow,deny
        Allow from all
    Alias /static /var/www/yourflasksite/app/static
    <Directory /var/www/yourflasksite/app/static/>
        Order allow,deny
        Allow from all
    ErrorLog ${APACHE_LOG_DIR}/yourflasksite-error.log
    LogLevel warn
    CustomLog ${APACHE_LOG_DIR}/yourflasksite-access.log 

Visual programming for environmental research with UAVs


I’ve recently begun a new project with Karen Anderson who runs the UAV research group at the Exeter University Environment and Sustainability Institute. We’re looking at using commodity technology like android phones for environmental research with drones. Ecology research groups and environmental agencies have started using drones as a replacement for expensive and risky light aircraft for gathering data on changes to landscapes due to climate change and erosion. How can we make tools that are simpler and cheaper for them to set up and use? Can our software also be relevant for children using kites in cities for making their own maps, or farmers wishing to record changes to their own fields themselves?

Enumerating and displaying all the sensors on a phone
Enumerating and displaying all the sensors on a phone

This is a more open ended project than our previous environmental and behavioural projects, so we’re able to approach this with an R&D perspective in relation to the technology. One of the patterns I’ve noticed with this kind of work is that after providing scientists with something that meets their immediate needs, it inspires a ton of new ideas and directions – and I become a bottleneck. Ideally I need to provide something that allows them to build things themselves once they have an understanding of all the possibilities, also adapting to needs ‘in the field’ is an important aspect of the kind of work that they do – which can be in remote locations anywhere in the world.

Some time ago I had a go at porting my musical livecoding language scheme bricks to android for the open sauces project. I’m now applying it as a way of configuring sensor data acquisition and recording by drag/dropping a visual programming language. It’s early days yet, I’m still debugging the (actually rather amazing) android drag/drop API – here are some initial screenshots.

Nested drag/droppable code which gets converted to Scheme code for the tinyscheme interpreter
Nested drag/droppable code which gets converted to Scheme for the tinyscheme interpreter
A block menu works much like Scratch, allowing you to pick new code blocks (this code is nonsense - just testing!)
A block menu works much like Scratch, allowing you to pick new code blocks (this code is nonsense – just testing!)
The "Hello World" program, displays every 3 seconds  (even when the app is running in the background)
The "Hello World" program, displays every 3 seconds (even when the app is running in the background)