More photos from the Makernow fablab, the pattern matrix weavingcoding device is starting to take shape! All schematics, 3d printing shapes and plans will be released soon as open source hardware on the weavecoding repo.
New tangible weavecoding device – pattern matrix
We’re starting construction of version 2 of the flotsam tangible programming device, specialised to weaving – and henceforth known as the ‘pattern matrix’. This will be tested during May at our upcoming performance/workshop/residency at Munichâ€™s Museum fÃ¼r AbgÃ¼sse Klassischer Bildwerke (Museum of Casts of Classical Sculpture) with the Coding weaves project, and then for later use in Cornwall (more on that part soon).
The first thing we are exploring is removing the need for physical plugs – although I like them a lot, they are problematic for people as it takes time to learn how to align the blocks in the current prototype. In order to get around this, and maintain the cheapness of the programming blocks themselves we’re looking at using magnetism to represent information. We can use blocks with no connections, painted white and black on different sides and detect their orientation and position via a magnet in the centre.
Initially this idea came from thinking about reed switches with Francesca, and playing with mobile phone magnetometers on the UAV project led to us investigating Hall effect sensors (the building blocks of magnetometers). We had a bit of a testing workshop with Andy from the Falmouth University makernow fablab who are helping with construction of this project.
Hall effect sensors allow us to detect the polarity of nearby magnetic fields – and seem to be restricted enough in range that they can be very precise. Even with fairly weak magnets we found we could put the sensors right next to each other (see above) and still determine the difference between two opposed or aligned fields.
For the warp/weft weave pattern structure we only need 1 bit of information to be detected, but for future extensibility for the yarn colour programming setup it’s important to be able to read more (4 bits are encoded in the flotsam blocks).
Our plan is to try putting 4 sensors in a square which adds an intriguing possibility of rotating the blocks to change their meaning, as well as flipping them. The great thing is that this gets very close to tablet weaving in terms of the notation and the actions required. We can also represent all 16 states with only 4 blocks – if negative is 0 and positive is 1, and we read the code as binary clockwise from top left:
Starting state [0,1,5,6] - - + - + - - + - - - - - + - + Rotate clockwise [0,2,10,12] - - - + - + - - - - - - + - + + Horizontal flip [15,11,10,12] + + + + - + - - + + + - + - + + Rotate counter-clockwise [15,13,5,6] + + + - + - - + + + + + - + - + Vertical flip [0,4,5,6] - - - - + - - + - - - + - + - +
Here is Andy’s design for the PCB we’ll use under each of the 25 board locations:
Coding structure with threads
One of the most inspiring things we heard from Leslie Downs (our Advisor on textile innovation) was about the way he manufactures high specification structures for aerospace engineering by weaving on ordinary looms, sometime even hand looms for their flexibility. It turns out that some of these techniques are also possible with tablet weaving: I came across this mysterious diagram in ‘Byways in Handweaving’ by Mary Meigs Atwater:
The text doesn’t really go into much detail about what you can do with “Icelandic double weave”, nor is there much information online that I could find, so I had a play. Normally you weave tablets by rotating the cards quarter turns and using the shed between the top/bottom sides of the cards with them straight. With this technique you rotate quarter turns back and forward from the orientation in the diagram instead, and use two separate wefts for the top and the bottom sheds. This results in two separate fabrics woven at the same time which can be reattached by going back to normal weaving, or crossed over like this:
This technique is very versatile and results in strong structures. It’s possible for example to connect the weaves along the edges and create long tubes or weave more than two layers attached in different ways. In this way, weaving is an ancient 3D printing process that converts code into structure (and only produces biodegradable waste).
There are some things that you can only do with tablet weaving. As the ‘loom’ as such is just a disconnected pack of cards it’s possible to reorganise it as you go along, for example if you use two wefts and split the weave in half, you get two separate fabrics which can be rejoined later on – they don’t even need to be connected in the same way, I tried crossing them over here – which seemed to work easily enough:
With the use of four wefts you can even do a double layer weave at the same time as a split like this to create more complex structures, I had a go at that but I ended up with my threads in a mess and accidentally attached the two layers by mistake – I need more practice, and possibly using more than 10 cards would help too.
You can also turn corners with tablet weaving, my first attempt at that wasn’t so great as I found it really difficult to maintain the tension and lost count of my wefts, but you do this by simply gradually adding extra wefts to one side of the weaving. I attempted a full “u-turn”, shown here after some smaller double weave sections:
It would be interesting to think about how to add these structural modifications to the current tablet language. They all involve adding/removing wefts or skipping warp threads with wefts – notating this is probably fairly simple, but modelling the results would be very challenging indeed, if it’s even possible.
Test pattern rendered in threads
A language for Tablet weaving
After the tablet weaving experiment, here is an attempt at a language/notation for understanding it better. You can have a go here.
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) (repeat 4 (weave-forward 4) (weave-back 4))
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) (rotate-forward 0) (repeat 4 (weave-forward 4) (weave-back 4))
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.
(weave-forward 7) (twist 0 1 2 3) (weave-back 1) (repeat 2 (weave-forward 2) (weave-back 2)) (weave-forward 1) (twist 2 3 4 5) (weave-back 1) (repeat 2 (weave-forward 2) (weave-back 2)) (weave-forward 1) (twist 1 2 5 6) (weave-back 1) (repeat 2 (weave-forward 2) (weave-back 2))
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:
(weave-forward 1) (twist 0 2 4 6) (repeat 4 (twist 3) (weave-forward 4) (twist 5) (weave-back 4))
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.
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.
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.
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.
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) (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.
Tangible weavecoding at the Makernow Fablab
Demoing the flotsam tangible livecoding device at the Makernow Fablab in Penryn. Future revisions of the hardware will need to fix some of the problems identified in testing as well as work in gallery exhibitions we have planned for next year.
Tangible livecoding tests in the wild, and material as type in programming
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.