A cryptoweaving experiment

Archaeologists can read a woven artifact created thousands of years ago, and from its structure determine the actions performed in the right order by the weaver who created it. They can then recreate the weaving, following in their ancestor’s ‘footsteps’ exactly.

This is possible because a woven artifact encodes time digitally, weft by weft. In most other forms of human endeavor, reverse engineering is still possible (e.g. in a car or a cake) but instructions are not encoded in the object’s fundamental structure – they need to be inferred by experiment or indirect means. Similarly, a text does not quite represent it’s writing process in a time encoded manner, but the end result. Interestingly, one possible self describing artifact could be a musical performance.

Looked at this way, any woven pattern can be seen as a digital record of movement performed by the weaver. We can create the pattern with a notation that describes this series of actions (a handweaver following a lift plan), or move in the other direction like the archaeologist, recording a given notation from an existing weave.

A weaving and it’s executable code equivalent.

One of the potentials of weaving I’m most interested in is being able to demonstrate fundamentals of software in threads – partly to make the physical nature of computation self evident, but also as a way of designing new ways of learning and understanding what computers are.

If we take the code required to make the pattern in the weaving above:

(twist 3 4 5 14 15 16)
(weave-forward 3)
(twist 4 15)
(weave-forward 1)
(twist 4 8 11 15)

(repeat 2
 (weave-back 4)
 (twist 8 11)
 (weave-forward 2)
 (twist 9 10)
 (weave-forward 2)
 (twist 9 10)
 (weave-back 2)
 (twist 9 10)
 (weave-back 2)
 (twist 8 11)
 (weave-forward 4))

We can “compile” it into a binary form which describes each instruction – the exact process for this is irrelevant, but here it is anyway – an 8 bit encoding, packing instructions and data together:

8bit instruction encoding:

Action  Direction  Count/Tablet ID (5 bit number)
0 1         2              3 4 5 6 7 

Action types
weave:    01 (1)
rotate:   10 (2)
twist:    11 (3)

forward: 0
backward: 1

If we compile the code notation above with this binary system, we can then read the binary as a series of tablet weaving card flip rotations (I’m using 20 tablets, so we can fit in two instructions per weft):

0 1 6 7 10 11 15
0 1 5 7 10 11 14 15 16
0 1 4 5 6 7 10 11 13
1 6 7 10 11 15
0 1 5 7 11 17
0 1 5 10 11 14
0 1 4 6 7 10 11 14 15 16 17
0 1 2 3 4 5 6 7 11 12 15
0 1 4 10 11 14 16
1 6 10 11 14 17
0 1 4 6 11 16
0 1 4 7 10 11 14 16
1 2 6 10 11 14 17
0 1 4 6 11 12 16
0 1 4 7 10 11 14 16
1 5

If we actually try weaving this (by advancing two turns forward/backward at a time) we get this mess:


The point is that (assuming we’ve made no mistakes) this weave represents *exactly* the same information as the pattern does – you could extract the program from the messy encoded weave, follow it and recreate the original pattern exactly.

The messy pattern represents both an executable, as well as a compressed form of the weave – taking up less space than the original pattern, but looking a lot worse. Possibly this is a clue too, as it contains a higher density of information – higher entropy, and therefore closer to randomness than the pattern.

Pixel Quipu

The graphviz visualisations we’ve been using for quipu have quite a few limitations, as they tend to make very large images, and there is limited control over how they are drawn. It would be better to be able to have more of an overview of the data, also rendering the knots in the right positions with the pendants being the right length.

Meet the pixelquipu!


These are drawn using a python script which reads the Harvard Quipu Database and renders quipu structure using the correct colours. The knots are shown as a single pixel attached to the pendant, with a colour code of red as single knot, green for a long knot and blue as a figure of eight knot (yellow is unknown or missing). The value of the knot sets the brightness of the pixel. The colour variations for the pendants are working, but no difference between twisted and alternating colours, also no twist direction is visualised yet.


Another advantage of this form of rendering is that we can draw data entropy within the quipu in order to provide a different view of how the data is structured, as a attempt to uncover hidden complexity. This is done hierarchically so a pendant’s entropy is that of its data plus all the sub-pendants, which seemed most appropriate given the non-linear form that the data takes.



We can now look at some quipus in more detail – what was the purpose of the red and grey striped pendants in the quipu below? They contain no knots, are they markers of some kind? This also seems to be a quipu where the knots do not follow the decimal coding pattern that we understand, they are mostly long knots of various values.


There also seems to be data stored in different kinds of structure in the same quipu – the collection of sub-pendants below in the left side presumably group data in a more hierarchical manner than the right side, which seems much more linear – and also a colour change emphasises this.


Read left to right, this long quipu below seems very much like you’d expect binary data to look – some kind of header information or preamble, followed by a repeating structure with local variation. The twelve groups of eight grey pendants seem redundant – were these meant to be filled in later? Did they represent something important without containing any knots? We will probably never know.


The original thinking of the pixelquipu was to attempt to fit all the quipus on a single page for viewing, as it represents them with the absolute minimum pixels required. Here are both pendant colour and entropy shown for all 247 quipu we have the data for:



Quipu: further experiments in Düsseldorf

A report on further experimentation with Julian Rohrhuber and his students at the Institute for Music and Media in Düsseldorf during our coding with weaves and knots remote seminar this week.


As we have so little idea what the Inca are telling us in their Quipu, it seems appropriate to add a cryptanalysis approach to our toolkit of inquiry. One of the first things that a cryptanalyst will do when inspecting an unknown system is to visualise it’s entropy in order to get a handle on any structures or patterns in the underlying information. This concept comes from Claude Shannon’s work on information theory in the 40’s, where he proved that information obeys fundamental laws of physics. The concept that information and “cyberspace” may not be as intangible and otherworldly as we might believe (in fact is grounded in physical reality along with everything else) is one of the recurring themes of the weavingcodes project.

Shannon’s innovation was to separate the concepts of data quantity from information value, and he claims that information is equivalent to surprise – the more surprising a piece of data is, the more information it contains. Conversely a piece of information which we expect to hear by definition doesn’t really tell us very much. The potential for some data to be surprising (or more specifically it’s potential to reduce our uncertainty) can be measured statistically, with a quantity he called entropy, as it is analogous to states in thermodynamic systems.


Shannon defined a generalised communication system, which is handy to give us a way of reasoning about our situation in relation to the Inca. Our main unknown is the source of the messages they are sending us, are they accounting information, calendars or stories? We know a bit more about the transmitters of the messages, the khipukamayuq – the knot makers and quipu keepers. At the time Shannon was working on information theory, he was part of the start of the movement away from analogue, continuous signals and towards digital signals – with advantages that they are highly resistant to noise and can be carried further and combined together to increase bandwidth. Quipu are also mainly comprised of digital information – the type of a knot, the number of turns it’s comprised of or the twist direction of a thread are all discreet (either one thing or another) and therefore highly robust to material decay or decomposition. We can still ‘read’ them confidently after 500 years or more without the digital signal they represent being degraded too badly, if only we could understand it. At the same time, none of us working on this have access to a real quipu, so our receivers are the archaeologists and historians who study them, and compile archives such as the Harvard Quipu Archive we are using.

Although entropy is a very simplistic approach mathematically, it’s main use is to give us a tool for measuring the comparative information carrying potential of data which we have no idea about. Here are all the quipu in the Harvard database in order of average entropy bits they contain (only listing every other quipu ID):


This graph is calculated by making lists of all the discreet data of the same type, e.g. knot value, type, tying direction, pendant colours and ply direction (ignoring lengths and knot positions as these are continuous) – then calculating Shannon entropy on histograms for each one and adding them together.

We can also compare different types of information against one another, for example the main data we currently understand has some specific meaning are the knot values, partly derived from the knot type (long, single or figure of eight), which represent a decimal notation. If we compare the entropy of these we can expect them to have roughly similar average amounts of information:


The meanings of colours, ply and structure are largely unknown. Here are the knot values compared with the colours:


And this is pendant ply direction compared with knot values for each quipu:


At this point the most useful aspect of this work is to give us some outliers to inspect visually and sonically – more on that soon.

Photos from the machine wilderness workshop

Busy times at Foam Kernow, here are some photos from the Machine Wilderness Workshop weekend before last. This was a project between Foam Amsterdam and us, with 30 participants from all over the place geographically and professionally. My role was as facilitator, so mainly obtaining raw materials (electronic toys, recycled trash and e-waste) as well as a bit of cooking and general running around which I found very enjoyable. The machines invented and prototyped were grounded in the environment of the Penryn river in Cornwall, so common themes were seaweed biomimicry and experiments with estuarine mud, both as a surprisingly rich power source as well as a design medium in it’s own right.

I’ll leave the in-depth write ups to those leading the event, but one of my interests was to see how a workshop involving e-waste would work, practically and as an inspiration – with an eye to doing this with primary school kids and teachers. We managed to locate a good quantity of old toys from various local second hand stores and warehouses, quite a modest outlay in return for some very good mechanics, motors and electronic parts. Resisting the temptation to take them to bits beforehand meant that the participants could open them up and discover what they could use, one of the best items was a bubble machine – inside was a good air pump and lots of mechanics (total cost ~£1.50). This was incorporated into a robot lifeform that was in part augmented by moss growth and LED lights.

See the rest of the photos here.






The UAV toolkit & appropriate technology

The UAV toolkit’s second project phase is now complete, the first development sprint at the start of the year was a bit of research into what we could use an average phone’s sensors for, resulting in a proof of concept remote sensing android app that allowed you to visually program different scripts which we then tested on some drones, a radio controlled plane and a kite.


This time we had a specific focus on environmental agencies, working with Katie Threadgill at the Westcountry Rivers Trust has meant we’ve had to think about how this could be used by real people in an actual setting (farm advisors working with local farmers). Making something cheap, open source and easy to use, yet open ended has been the focus – and we are now looking at providing WRT with a complete toolkit which would comprise a drone (for good weather) a kite (for bad weather/no flight licences required) and an android phone so they don’t need to worry about destroying their own if something goes wrong. Katie has produced this excellent guide on how the app works.

The idea of appropriate technology has become an important philosophy for projects we are developing at Foam Kernow, in conjunction with unlikely connections in livecoding and our wider arts practice. For example the Sonic Bike project – where from the start we restricted the technology so that no ‘cloud’ network connections are required and all the data and hardware required has to fit on the bike – with no data “leaking” out.


With the UAV toolkit the open endedness of providing a visual programming system that works on a touchscreen results in an application that is flexible enough to be used in ways and places we can’t predict. For example in crisis situations, where power, networking or hardware is not available to set up remote sensing devices when you need them most. With the UAV toolkit we are working towards a self contained system, and what I’ve found interesting is how many interface and programming ‘guidelines’ I have to bend to make this possible – open endedness is very much against the grain of contemporary software design philosophy.

The “app ecosystem” is ultimately concerned with elevator pitches – to do one thing, and boil it down to the least actions possible to achieve it. This is not a problem in itself, but the assumption that this is the only philosophy worth consideration is wrong. One experience that comes to mind recently is having to make and upload banner images of an exact size to the Play Store before it would allow me to release an important fix needed for Mongoose 2000, which is only intended to ever have 5 or 6 users.


For the UAV toolkit, our future plans include stitching together photos captured on the phone and producing a single large map without the need to use any other software on a laptop. There are also interesting possibilities regarding distributed networking with bluetooth and similar radio systems – for example sending code to different phones is needed, as currently there is no way to distribute scripts amongst users. This could also be a way of creating distributed processing – controlling one phone in a remote location with another via code sent by adhoc wifi or SMS for example.

Procedural weave rendering

We’ve been working on new approaches to 3D rendering ancient weaves, using Alex’s new behavioural language (which describes a weave from the perspective of a single thread) as the description for our modelling. This new approach allows us to build a fabric out of a single geometric shape, where warp and weft are part of the same thread.


This is mix of tabby and 2:2 twill, created by this code:

warp 12 24 ++ [TurnIn] ++ threadWeftBy'' Odd (rot 3) ([Over,Under]) 12 12 ++ threadWeftBy'' Odd (rot 3) ([Over,Over,Under,Under]) 12 12

I’m still learning this language, but more on that soon. This line produces an large list of instructions the weave renderer uses to build it’s model, turning the thread and shifting it up and down as it crosses itself.

In the video in his last post Alex describes using this to mix two separate weaving techniques together, which is one of our main reasons for developing this language – existing weave simulations cannot replicate the weaving technology of the ancient Greeks who for example, combined tablet and warp weighted weaving in the same fabric.

The second problem with weave simulations is shown by the following screenshot from a popular existing system:


Fabrics modelled in this way are considered to infinitely repeating sections with chopped off threads. There is no consideration for the selvedge at the edge of the fabric – which as we’ve shown in our past research is almost like a completely separate weave system of it’s own, and rarely considered by notation systems or modelling (and often left to the weaver to ‘livecode’). Here is a different view of the same fabric:


We can also now introduce other changes to the yarn structure, for example modifying the width using a sine wave.


I still have a few glitches to fix as you can see above, but here is a video of the development process from the first script, getting the polygons lined up, fixing the turning, adding over/under, reading Alex’s code and finally lining everything up.

Weavecoding performance experiments in Cornwall

Last week the weavecoding group met at Foam Kernow for our Cornish research gathering. As we approach the final stages of the project our discussions turn to publications, and which ideas from the start need revisiting. While they were here, I wanted to give local artists and researchers working with code and textiles a chance to meet Ellen, Emma and Alex. As we are a non-academic research organisation I wanted to avoid the normal powerpoint talks/coffee events and try something more informal and inclusive.


One of the original ideas we had was to combine weaving and coding in a performance setting, to both provide a way to make livecoding more inclusive with weaving, and at the same time to highlight the digital thought processes involved in weaving. Amber made vegetarian sushi for our audience and we set up the Jubilee Warehouse with a collection of experiments from the project:

  • The newly warped table loom with a live camera/projection from underneath the fabric as it was woven with codes for different weaves on post-it notes for people to try.
  • The tablet/inkle loom to represent ancient weaving techniques.
  • The pattern matrix tangible weavecoding machine and Raspberry Pi.
  • A brand new experiment by Francesca with a dancemat connected to the pattern matrix software for dance code weaving!
  • The slub livecoding setup.


This provided an opportunity for people to try things out and ask questions/provide discussion starting points. Our audience consisted of craft researchers, anthropological biologists, architects, game designers and technologists – so it all went on quite a lot longer than we anticipated! Alex and I provided some slub livecoded music to weave by, and my favourite part was the live weaving projection – with more projectors we could develop this combination of code and weaving performance more. Thanks to Emma for all the videos and photos!



Airborne drag-drop programming, the next steps

This autumn we are continuing work on the UAV toolkit with Karen Anderson and her research group at the Environment and Sustainability Institute. This time we have a mission to help the Westcountry Rivers Trust by coming up with fast and cheap ways they can build maps of farms to determine water run-off problems, which gives farmers proof they need to get funding to fix pollution issues.

Flight planning operations and photo checking

In order to make the software usable in this case, we decided on two directions. On the one hand there needs to be a simple way to start and stop programs (or “flight modes”) that read sensor data, as well as defining certain global settings, ie. flight altitude, desired image coverage etc. At the same time, the code to define what this does needs to still be programmable in the app – and more complex behaviours need to be possible to support both kites and UAVs. Our philosophy is that it has to be open ended, as we don’t know where the toolkit it might be useful (ie. crisis mapping situations) or what new sensors will be available on a device in the future.

The new main screen

One specific set of new behaviours we need is for kite mapping. We already have the ability to choose when to take pictures based on GPS and altitude, but with a kite there can be lots of turbulence and the camera is in a much less controlled state, flipping around taking shots of the sky etc. So we need to calculate things like jerk from change in acceleration and use orientation sensors to only take photos when the lens is pointing directly down, within some degree of acceptable margin.

Below is a section of the code that calculates if we are pointing down using the magnetometer and accelerometer – the drag drop visual code can now be used to build normal Scheme functions using a touchscreen (a bit like scheme bricks). In fact I managed to do all of this work on the phone. There are now two types of code, the main programs or “flight modes” that you can run from the front screen, and a library of editable functions which they use. This means there are now three levels that the software can be used – using it without needing to see any of the code at all, editing the basic behaviour like which sensor’s data are captured, and finally modifying the more detailed code to make it do completely new things.


Warping a 4 shaft table loom

The next stop on my exploration of loom technology for the weavingcodes project (after building a frame loom and learning tablet weaving) has been learning how to use a 4 shaft table loom. This has been kind of daunting to me, as it’s a much more modern weaving device than I’ve been working with up to now (frame looms and tablet weaving can be considered to be both neolithic digital tech). I also couldn’t really figure out much from books on the warping techniques, as it’s difficult to get the idea through images – so I had to just kind of jump in and try it.

I decided to use the double weave draft plan to start with from my last post – partly as I want to try this technique, but also it’s pretty simple warp threading for a first attempt.


The next step was to choose the material. A while back I bought 200gms of good quality 8/2ne cotton/linen mix which I’ve been saving for something like this. In order to calculate the amount of fabric the yarn will produce you can wrap it lightly around a ruler:


This yarn is about 10 threads per centimetre, so we can use that to figure out roughly how many warp threads (or ‘ends’) to use – I decided on 160 ends in total (so ~16cm wide) comprised of the two alternating colours. I wound out two sets of 80 threads over a couple of metres, doing both colours at once to make it easier. I then attached each one to the back roller and wound them in a bit – this would have worked better later if I had used more bundles of fewer threads.


You can see in the picture I’ve also bolted a “raddle” (thing with nails) on the back beam of the loom to help space out the warp threads – this is important later on. Now we come to the heddles. The threading chart is what programs this part of the loom, which in turn forms a fixed instruction set of pattern possibilities for the weave. You can see the 4 levers that operate the frames in the photo above – these essentially give us 4 bits per weft of information. 2 of the 16 possibilities are invalid – as all frames raised or lowered doesn’t provide a working fabric. Using different sequences of these 14 combinations for each weft thread, the possibilities become mathematically huge – even with a fixed warp like this.


Reading the frames and warp colours from the chart to provide a sequence, you hook each warp end through the eye of the heddle – this was the most time consuming part of the process.


Once that is done, the reed – which is attached to the beater and used to pack down and keep the fabric evenly spaced, is threaded (or “sleyed”). The reed I used was a bit too course so I used two threads per gap – this could have done with being a bit more as it turned out.


With all this done the warp ends can be attached to the front roller and the whole warp can be wound on through the heddles and back again to check the tension. Of course in practice (and as it was my first time) it actually involved a lot of tangles and swearing, and two broken warp threads, fairly easily knotted back together. The raddle was essential in helping untangle the warp threads, but I also had to fiddle around with the tension a lot, retying the knots attaching them to the rollers and using plenty of sticks (it seems you can never have too many sticks when warping a loom). This is a test that the warp is threaded correctly, with all black threads (frames 2 and 4) lifted – phew!


After that we could try a little test weaving, going freestyle on the heddles.


It turns out the reed is a little too wide, meaning it’s stretching the warp out as the woven fabric finds it’s true width – switching to a new one is possible without needing to do the heddles again, so we’ll see how it goes. Compared with tablet weaving, this is far more mechanised and efficient in terms of fabric production, but the flipside to that is that you lose a lot of flexibility, and the loom is less responsive to particular material properties like this.

“The mystery of the drawdown”

Double weave has intrigued me since first figuring out how it works with tablets – it shows how weaving is a 3D process, and is an example of shape making from code. It’s the starting point for more advanced methods for creating strong woven composite materials and structures. I’ve been reading this document by Paul O’Connor to understand the process for a 4 shaft loom. He includes this critique on current methods for visualising weaving:

The traditional method for creating the drawdown shows all the warp and all the weft threads in one layer. What is needed is a way to make two drawdowns, one for the top cloth layer and the other for the bottom cloth layer. Most of the commercially available computer weave programs display the drawdown in this same fashion, as a single layer.

This is a draft plan (the traditional notation technique) for double weave which contains the drawdown he’s talking about:


Drawdowns are designed for thinking about weaving as 2D pattern, and like any notation system they abstract a situation so we can reason about it, with the trade-off that they make it impossible to understand different aspects. This is a big problem we have in programming too – and is the reason we need to have many levels and hundreds of different languages to describe problems. I’ve noticed that if people (or organisations) stick with one too long, the specialisation starts to hinder ability to even recognise certain issues. It’s interesting to see such a clear analogy here.

In order to see what’s really happening with double weave, we need to switch to a different notation and look at the structure more closely:


Hopefully you can see that all of the black threads are sitting on top of all the white threads, and forms it’s own plain or tabby weave fabric. The same is true for the white threads underneath. Below is the same structure rendered in the weavecoding dyadic device – this shows the heddles that need raising to create the sheds in the lift plan, and you can see a repeating zigzag pattern. As an aside, I’ve noticed that there seems to be some kind of underlying categorisation of lift plan patterns which I’ve not found mentioned anywhere yet – something else to look into at some point.