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.

double

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:

IMG_20151006_112054

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.

IMG_20151005_111456

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.

doublethreading

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.

IMG_20151005_115731

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.

IMG_20151006_120920

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!

IMG_20151009_133825

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

IMG_20151009_171547

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.

Spork factory

A system for creating an abundance of useless software for tiny devices. Spork Factory evolves programs that run on Atmel processors – the same make as found on the Arduino, in this case the ATtiny85 – a £2.50 8 pin 8bit CPU. I’m currently simply using a piezo speaker as an output and evolving programs based on the frequency of the sound produced by flipping the pins up and down, so creating 2bit synths using the Fourier transform as the fitness function. With more hardware (input as well as output) perhaps we could evolve small robots, or even maybe cheap claytronics or programmable matter experiments.

This project reuses the previous genetic programming experiments (including jgap as its genetic algorithm framework), and is also inspired by Till Bovermann’s recent work with Betablocker in Supercollider for bytecode synthesis.

The programs generated don’t use the Atmel instruction set directly, but interpret a custom one derived from Betablocker for two reasons. Atmel processors separate their instruction memory from data (the Harvard architecture) which makes it difficult to modify code as it’s running (either uploading new evolved code or running self modifying instructions), the other is that using a simplified custom instruction set makes it easier for genetic algorithms to create all kinds of strange programs that will always run.

I’ve added an ‘OUT’ instruction, which pops the top of the stack and writes it to the pins on the ATtiny, so the first thing a program needs to do is generate and output some data. The second thing it needs to do is create an oscillator to create a tone, after that the fitness function grades the program on the amount of frequencies present in the sound, encouraging it to make richer noises.

Here are two example programs from a single run, first the ancestor, a simple oscillator which evolved after 4 or 5 generations:

out
out
nop
nop
dec
nop
nop
nop
out
nop
jmpz 254
nop
nop
nop
dup

It’s simply outputting 0’s, then using the ‘dec’ to decrement the top of the stack to make a 255 which sets the rightmost bit to 1 (the one the speaker is attached to) and then loops with the ‘jmpz’ causing it to oscillate. This program produces this fft plot:

After 100 or so further generations, this descendant program emerges. The dec is replaced by ‘pshl 81’ which does the same job (pushes the literal value 81 onto the stack, setting our speaker bit to 1) but also uses a ‘dup’ (duplicate top of the stack) to shuffle the values around to make a more complex output signal with more frequencies present:

out
out
not
nop
pshl 81
pshi 149
out
nop
out
nop
dup
psh 170
jmp 0

Some further experiments, and perhaps even sound samples soon…

Touchscreen programming

As more and more people use touchscreens, it still irks me that we lack good ways of programming “on” devices reliant on them (i.e. native feeling – rather than modified text editors). As a result they seem designed entirely around consumption of software (see also the “The coming war on general-purpose computing”).

So lets make them programmable. Recent steps in this direction are based on Jellyfish – an idea to create a kind of locative livecoding virus game (more on that as it unfolds), starting with fluxus on android (now called nomadic) and a good dose of Betablocker DS, mixed with some procedural 3D rendering inspired by the Playstation2’s mad hardware, and icons previously seen on the Supercollider 2012 flier!

This is a screenshot of it’s current early state, with the Linux/Android versions side by side (spot the inconsistency in wireframe colour due to differences in colour material in OpenGL ES). Main additions to the previous android fluxus are texturing and text rendering primitive support. I’m glad to say that pinch-to-zoom and panning are already working on the code interface, but it’s not making too much sense yet to look at.