Eduardo Marisca | 30 Dec 2015
Â
A couple weeks ago, I had the unexpected opportunity to try my chance at weaving. While spending a few days down in Ica, in the south of Lima, I spent an afternoon at an artisanal weaving shop where I got to play around with an old-school hand-operated loom, under the close supervision and orientation from the professional weavers who work there every day. It’s a laborious, mechanical process, as slowly you weave every line and every thread on top of the last one and little by little you begin to assemble a textile. And it got me thinking about a lot of the nuances of craft work, machinery, and ultimately computation.
The loom I operated was a simple yet very interesting machine. A series of pedals allow you to spread open or “shed” the warp threads that run across the loom, for the purpose of running a weft thread across using a “shuttle” — these are all terms I’ve just learnt, by the way, so I might very well be using them wrong. The pattern in which you push the pedals determines which threads are shed, and alternating between different pedal patterns allow you in turn to assemble different patterns on the textile by using differently coloured threads. If you know what you’re doing, then you can begin to consciously assemble the pattern that you want following these rules; if, like me, you have trouble following instructions and just want to play around, then you can try multiple varieties of combinations for patterns that are more random in nature.
Operating the loom is especially interesting because the results of your operation are immediately visible to you: use un pedal combination, run the thread, and the result is right there for you to examine. This makes it very easy to examine and debug your technique, especially since your next iteration cycle is basically the next thread you run. The textile that you build is at the same time your learning and experimentation history, all of it there for you to observe. The textile grows slowly enough for you to understand, yet fast enough for you to experiment. As a learning metaphor, it’s a fascinating experiment, as are the shop dynamics that quickly begin to emerge when you start working: out of a group of four of us trying our hands at the loom, we quickly found ourselves giving each other hints and tips, and asking questions to the person next to us regarding how to do one thing or another.
It became impossible for me not to think about computation: once you see the kind of pattern that begins to emerge, and how by alternating colours you’re basically constructing a drawn-out punch card, you can also begin to think about ways in which you could encode and program messages within the thread as if it were binary code. Of course, it is super slow binary code, which makes it mostly useless, but you can also begin to see how the operation of the loom could be automated (and of course it has been for hundreds of years) to optimise this process. With a mechanised or automated loom, you could imagine a process that simplified the encoding of messages and information onto the threads — a very rudimentary form of computation, interesting because of its blatant materiality but also because of its demanding physicality. We rarely think about these production processes nowadays, especially those of use who site behind laptop screens most of the day and stare at our smartphones the rest of the time. But operating the loom was very physically demanding, and making even little bits of progress took enormous time, effort, and concentration. It’s nice to be reminded of the importance and complexity of craft work by actually doing it.
So a few days later I decided to expand upon this a bit — I had worked the loom and was able to produce something mildly appealing out of it, a piece that casually resembled a low-fi, textile version of pixel art. How else could I expand on it? Just a weaving and looming had shed some insight into the work of computation, how might computation shed some insight into the craft of weaving?
I started recreating the logic of the loom in a digital environment. First I needed to understand the rules, and how the rules mapped out onto actual pattern results. Before trying my hand at any code, I began by mapping what the patterns looked like using a simple spreadsheet — just to get a sense for how the rule system would play out and the various combinations that would need to be digitally recreated.
Once I had these mapped out, I began reconstructing my digital loom using Processing (basically because I figured it’d be faster and easier to begin making visual things with Processing than other things). Of course, every feature and function of the loom has to be digitally mapped: the pedal sequences (shedding), threading and colour switching (shuttling), as well as the pattern logic itself to begin assembling the digital textile based on what your expectations are.
Of course, the digital loom operates differently than the physical loom. For one, it’s insanely faster. Processing actually allows you to slow down the rendering speed of an animation so you can actually see what’s going on, but for a computer it’s trivial to just render endless screens of lines in no time. Reproducing the line-by-line nature of the loom requires you to either use a much slower computer, or to artificially limit the processing speed.
Computation speed also means that your results at a large scale are immediate. One of the more interesting things for me about the loom was that your progress was visible after every thread was run. With the digital loom, all progress, past and future, is immediately visible once you establish the parameters. You don’t have to wait to see how a pattern will turn out — you just render it. And there’s trade-offs to doing this: there’s less of an appreciation of the technique, the effort and the craft that you get from using the loom; on the other hand, you gain an enormous experimental and iterative capacity. If you don’t like a pattern, you just change the parameters and tell the loom to run again.
This, in turn, can lead us to think back upon craft. What does traditional craft work look like when you begin to think about it from the vantage point of advanced digital manufacturing? What is the conceptual leap separating traditional craftsmanship from maker culture? How are traditional works of craft accelerated, improved or diminished by happing computation at their disposal? There’s no reason why craft should follow tech, but there’s also no reason why it shouldn’t explore it and experiment with it.
Having this sort of tools can push and challenge our notion of craftsmanship or augment the craft. Weavers able to visualise and project what their textiles will look like and to rapidly iterate on the results can then begin to push their craft further into areas previously considered to be too costly. I don’t mean to say this is necessarily better: it’s just an interesting challenge to think about.
The Processing sketch for the digital loom is available on GitHub if anyone wants to try it out. It has a very simple logic which should become evident upon exploring the code a bit: you have four different “pedal sequences” available which are alternated to construct patterns. The order in which you follow these sequences determines the output you get, and colour values are easily customisable. If possible, I’ll try to add some controls or settings to the process of building out these patterns can be further simplified.
But what’s most important to me here is the doubly reflexive nature of craft and tech. Exploring manual, mechanical craft can lead us to more nuanced understandings of technology in general and computation in particular, by examining how it operates at close and at extremely low “frame rates”. Similarly, accelerating craft to the speed of digital tech can raise interesting questions about craftsmanship, authorship, and creativity, as well as exaggerate and highlight the physical, material, and labour implications of the made world around us.
Â