Following my own code:
(twist 0 2 4 6)
Lets start simple:
The card rotations are shown on the left for each of the 8 cards, the predicted weaving is on the right for the top and bottom of the fabric. This is setup with a double face weaving on square cards, so black, black, white, white in clockwise from the top right corner.
(weave-forward 16) turns all the cards a quarter turn and weaves a weft and repeats this 16 times.
We can offset the cards from each other first to make a pattern.
rotate-forward turns only the specified cards a quarter turn forward without weaving a weft (
rotate-back also works):
(rotate-forward 0 1 2 3 4 5)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1)
We can’t really weave 32 forward quarter rotates without completely twisting up the warp so lets go forward/back 8 instead to make something physically weavable:
(rotate-forward 0 1 2 3 4 5)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1)
Now we get a zigzag – if we change the starting pattern again:
(rotate-forward 0 1 2 3 4 5 6)
(rotate-forward 0 1 2 3 4 5)
(rotate-forward 0 1 2 3 4)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1 2)
(rotate-forward 0 1)
This zigzag matches the stitch direction better. Instead of the rotation offsets we can also use
twist, which is more traditional, you can use it to form any pattern. It takes a list of cards to twist, and results in these cards effectively reversing direction compared to the others.
(twist 0 1 2 3)
(twist 2 3 4 5)
(twist 1 2 5 6)
The twist needs to happen when the cards are in the right rotation – if we repeat this example, but change the first
(weave-forward 7) to
(weave-forward 6) we get this instead:
If we put the twists in the loops, we can make small programs with complex results:
(twist 0 2 4 6)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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) (map2 (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) (foldl (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.
Last week I took the flotsam tangible livecoding system to my programming tutoring lesson for some first tests with the real experts. To provide some background, we started a while back with Raspberry Pi, messing around with the Minecraft API and python and we’ve recently moved on to laptops and pygame. I arrived with the system set up for the Minecraft building language, and we gave it 10 minutes or so before resuming normal activities – although it did get a bit more use during natural breaks in the lesson. Here’s a recent pic of the weaving l-system setup:
First impressions were that it was immediately playful, most of the blocks were eagerly removed and examined before we’d turned the thing on. One problem with this was that the chalk symbols rubbed off very quickly! A similarity with the Scratch programming language was also picked up on fairly soon.
A big issue was getting the connectors the right way round – this is not easy as the blocks are circular with little indication of which way is ‘up’. This could be fixed by altering the shape or cutting a little notch – learning how to manipulate them is part of the point, but right now it’s too difficult. This will also be a big problem in livecoding performance situations.
Using Minecraft, the screen was still a distraction. The connection between what’s happening in the 3D world and with the physical blocks is not obvious enough – even with the LED indicators. Also the mouse and keyboard need to be plugged in so we can move the camera around and see stuff, leading to a few too many things going on. I’m not sure how this can be solved regarding Minecraft, but indicates that a musical approach (with no screen or any other peripherals needed other than speakers) is the way to go.
Overall there is huge potential to think much more about the touch/feel of the blocks. Lots of these problems can be solved by using different shapes for different symbols (removing the need for chalk) with a clear orientation. Using different materials to provide textures and ‘feel’ in order to represent different sounds, or in terms of weaving, using the actual yarn material to represent itself is a huge area to explore.
In the photo above, I’m using thick and thin blue yarn wrapped around the blocks that represent them, and tinfoil for l-system rule symbols (X, Y and Z) – this is a kind of material based type indication. Interestingly the yarn feels very different even though it looks the same in the photo. In use this results in much less checking of the block when you pick them up, as your fingers tell you what they are.
I’ve collected images from our workshops in Leeds and Sheffield as we attempted to understand the intricacies of weaving, particularly ancient looms from antiquity.
A simple visualisation of a loom.
Attempting to understand the relationship between lift plans and heddles.
The connection between tablet woven bands, whose weft form the warp of the warp-weighted loom.
A pattern language, turning into binary pattern, then thinking about the types of patterns the weavers of antiquity favoured.
More tablet/warp weighted calculations, grouping threads by colour.
A professional lift plan, by Leslie Downes.
The second week of intense work on weavingcodes/codingweaves took place in the north of England, and began with a talk at the New Mechanics Institute show and tell meeting in Leeds. This was a good place to pick up from the previous week in Denmark as it included a talk on pixel art from the early days to contemporary forms that had many similarities with our slides.
The first half of the week was spent in Leeds University at the Interdisciplinary Centre for Scientific Research in Music where we met Tim Ingold who’s books (e.g. Making: Anthropology, Archaeology, Art and Architecture) have been a big influence on the project. One of the things we discussed with Tim was the cyberspace myth – the idea that computing is intangible and exists in some “other world” (or in a “cloud” somewhere) which is increasingly problematic. The need to highlight the physical basis of computation is one that this project is well placed to address – and if we consider weaving to be a form of computation, then it may be able to inspire approaches to programming that have at least three thousand years of history behind them. Tim also discussed knowledge as movement, his understanding of tacit knowledge – that which is otherwise unwritten or unspoken. Tacit knowledge is fluid and exists underneath a counterpart, called ‘articulated knowledge’ which is fixed by definitions. Culturally we have a bias towards articulated knowledge, and the idea of an unspoken knowledge is something which I realise I am trying to deal with in my teaching activities, but I’ve never been able to suitably describe it.
On day 2 we met with Leslie Downes – a retired professional weaver, who’s woven structures have gone into space, been used in jet engines and bullet proof vests.
There are many places where woven structures are superior to other kinds of manufacturing, but at the same time there is a lack of knowledge about weaving technology in engineering in general. Industrial fabric weaving has focused on increasing speed and production output while the kind of looms needed for materials like carbon fibre need to focus on precision. Leslie talked of occasions where he had to return to using hand looms to try out prototypes and how simulations of fibre interactions in weaving exist, but are unnecessary and deficient compared with prototyping with the actual materials. In weaving, as in computing, older tends to mean less restricted, as well as slower. New developments add to, rather than eclipse older ones.
The main feeling I had from Leslie was that his approach to technology came from a combination of an ability to reason about material based on a deep understanding of the capabilities of the looms themselves, how they can be adapted for each job (e.g. a project where he had to cut down the middle of a huge loom to remove a metre or so) mixed with experience in working with people to understand their needs. This generalist approach to knowledge is so lacking in society that it becomes highly regarded.
For the second part of the week we moved to Sheffield, and had breakfast with Luigina Ciolfi researcher in Human-Centred Computing. Lui’s input was both valuable and timely, as she pointed out that one of the key elements of interest is that nature of our collaboration, rather than any products we may or may not come up with. As such we need to be careful that we take the time to document our process and decision making.
After breakfast we headed into the woods – to a temporary base in The J G Graves Woodland Discovery Centre to shift into plotting and planning mode.
Emma Cocker joined us again, and helped to restrengthen the kairotic and poetic roots of our thinking and we were visited by the lovebytes crew to discuss the use of weaving and livecoding for teaching children. I set up the flotsam tangible programming prototype for it’s first ever use by anyone other than me. This involved a bit of code review/pair programming with Ellen in order to fix bugs in the weave generating algorithm.
We face challenges with our collaboration in both directions between our practices. On the one hand we have normal software decisions, is what we make going to be online or offline? Do we prioritise flexibility or accessibility for our choices in platforms and languages? How does what we do connect best with Ellen’s existing programming experience?
What we have decided is to work on a series of prototypes rather than focus on a monolithic development. The task then it so make sure we use common language for concepts across the project (perhaps using the concepts in the ancient greek as a grounding influence). Similarly, using protocols and formats to share common things between experiments – and fitting with existing programs and archives already in use where practical.
In the other direction, much of our discussion revolves around clarification of weaving practicalities and explanations – both of weaving in general and concepts and styles in use in antiquity. Both Alex and I need to start weaving if we are going to have a subtle enough understanding of the material we are dealing with. To this effect Alex already has a commission for a warp weighted loom in the works and I need to warp up the Harris loom.
We also have some fairly concrete projects to think about over the coming months, for example providing a good live-codable explanation of weaving to replace Ellen’s previous windows program as well as looking into the possibilities of using tangible programming in an art installation.
Two languages are working with Flotsam, the new name for the prototype screenless tangible programming language I’ve been building (which comes from the fact it’s largely made from driftwood). It’s somehow already been featured on the Adafruit blog!
The circuit seems to be fully debugged now, with short circuits fixed – which took a little while and more than a little frustration :) The Raspberry Pi python code is currently on the weavingcodes repository (more on this project on the kairotic site), and the first language is a declarative style L system for describing weave structure and pattern with yarn width and colour. The LEDs indicate that the evaluation happens simultaneously, as this is a functional language. The blocks represent blue and pink yarn in two widths, with rules to produce the warp/weft sequence based on the rows the blocks are positioned on:
The weaving simulation is written in pygame (which I’ve been using lately for teaching), and is deliberately designed to make alternative weave structures than those possible with Jacquard looms by including yarn properties. The version in the video is plain weave, but more complex structures can be defined as below – in the same way as Alex’s gibber software:
This is a completely different language for building shapes in Minecraft, and is an imperative, stack based language for driving a turtle in 3D space. Eventually (when I’ve manufactured a few more programming blocks) it will be possible to change Minecraft block materials and react to player actions. The LEDs indicate here the more sequential evaluation of this Forth like language:
All that’s needed to switch languages is to redraw the symbols with chalk and run a different script. It won’t be truly screenless until I write a musical language for it, which is obviously coming soon…