This is the second blog post of the “Towards Computational Craft” series.

This part is all about the process of knitting as seen through the lens of a computer scientist.

While the first part was a maifesto for structural rather than procedural knitting instructions, we will now take a look at hand-knitting as computation.

First off we can observe, that hand knitting needles both have a storage and a stitch processing function. For example when knitting socks, three or more needles may be used, only two of which are operated by the bi-manual human, while the other needles only serve to hold the stitches.

In terms of their storage function, knitting needles can be regarded as physical implementations of popular computer science concepts, namely the abstract data types referred to as stack and deque.

While straight needles with caps store and retrieve their stitches according to the principle of LIFO (last in – first out), double pointed and circular needles additionally implement the functions of a queue or FIFO (first in – first out), effectively forming a double ended queue, also known as deque.

While the needles constitute the main memory, there is an immense amount of external memory available. Free memory usually takes the form of the yarn ball, whereas allocated memory is constituted by the finished knitwork. Once a stitch is dropped off the needle it is automatically saved to the external memory. Every stitch can be modeled by a data structure with pointers to the subordinate stitches which it holds together.

There even is an automatic garbage collection accounting for dropped stitches: once the number of superordinate stitches referencing a stitch drops to zero, the whole stitch is dropped altogether, meaning that it is replaced by the null stitch, which only contains references to is neighbors but not to any subordinate stitch. This garbage collection mechanism gives rise to typical avalanche effects, generally known as runs or ladders.

To simulate loop formation and the slip-stitch-over operation, frequently encountered in hand knitting, the stack and dequeue functions are slightly extended by simple flip or “loop through” operator. This operator exchanges two stitches at the top of the stack or the end of the queue with the side effect, that the second stitch which takes over the prime position becomes subordinate to what was previously the first stitch.

The process of knitting is strictly sequential in nature, in contrast to the process of weaving, that may be considered an essentially parallel technique of fabric construction. In this respect knitting is similar to the Von Neumann architecture, but there are substantial differences in terms of the processing units: in the kind of computation performed by hand knitting there is no single CPU. Instead each needle point constitutes a decentralized processing unit, and pairs of such units operate in intimate interaction.

The fact, that straight needles do not have access to their very own working memory, explains the need for at least two needles in straight-needle based computation. The only notable exception to this “one hand washes the other” approach are some casting-on techniques, where the human hand performs functions that may also be taken over by a needle.

Although knitting needles have otherwise random access to the main memory both free and allocated, knitting operations are in practice mostly restricted to stitches that may be retrieved via the interface of the abstract data types and can be immediately released into the external storage.

The default stitch processing operation usually requires four clock cycles:

• First one stitch of the source needle S is copied to the destination needle D by pop and push operations.

• In the next cycle a null stitch is retrieved from the free external memory and is pushed onto D.

• In cycle 3 the flip operation is applied to D, which turns the null stitch into a real stitch, now serving as a superordinate stitch for the source stitch that has been copied over from S.

• finally the source stitch is dropped from the destination needle using pop. The last two cycles may be merged into a single one by concatenating flip and pop into a single slip-stitch-over operation.

To allow for variants of the knit stitch, such as purl, twisted knit and twisted purl, the orientation or twisting of the stitch must be part of its data structure.

To construct such stitches, we might either introduce left- and right-handed versions for elementary stitch operations such as push, depending on the side from which the needle enters the stitch.

Alternatively an isolated twist operation can be used, that only changes the orientation of the first stitch on the needle. While the first approach provides a more realistic model of the hand knitting process, the second approach may be preferred from an information processing point of view. In any case this is a matter of taste, since both systems are computationally equivalent.

So far I have introduced a lot of crazy analogies. You may consider some of them adventurous and daring, or you might even wonder why one would go as far as to break down a knitting-stitch into even smaller actions.

The reason is that once we have identified the atoms of the knitting process, we can use them as building-blocks for all kinds of hand-knitting stitches and knitting instructions.

And this is exactly what we will do in the third part of this series.

This blog post is the first one in a series of posts, in which I will take a radical information processing perspective on the process of knitting. As it happens this post is also a Cybercraftivist Manifesto for open craft formats.

This series is aimed both at computer-scientists who want to get a deeper understanding of the knitting process and at avid knitters, that would like to learn more about the kind of computation they are performing while they pursue their favorite pass-time. It is based on a computational model of hand-knitting that I developed for my diploma thesis in 2005.

Recently several people have emphatically ¹⁾ and critically ²⁾ discussed the idea of “Knitting as Programming”. In her excellent article Alex Bayley argued that it would be far more accurate to speak of “Knitting as Computation” but It seems like I am the only one who went as far as to identify the atomic actions of hand-knitting, pointing out the intimate relations between knitting and computation.

A few days ago I stumbled upon a workshop titled “Drawing, Weaving and Speaking Live Generative Music” ³⁾ by Alex MacLean (alias Yaxu).

In the workshop announcement he promised to “explore the historical and metaphorical connections between knitting and computation, and between code and pattern”.

If this is music to your ears, check out Yaxu's Article on “The Textural X” ⁴⁾ where he discusses the relations between knitting and livecoding featuring Tidal a Haskell-based programming language, where “Live coding music is very much like knitting with time”.

Yaxu considers the process of knitting from a functional programming perspective and the resemblance of knitting instructions and Tidal code is actually very striking.

In my computational model of knitting I took a more structural point of view. The idea is to identify the atomic units of knit-work as well as the operations used to manipulate them.

I believe that a big hurdle in trying to formalize knitting patterns, as in the case of KnitML was the pursuit to provide an XML format for instructions, rather than structures.

As every knitter knows, instructions differ radically between German knitting, English knitting, and even more for various types of knitting machines. Knitting instructions will always be inextricably linked to a specific knitting technique.

This inevitably results in a Tower-of-Babel-situation for knitting instructions.

Not only are there different knitting techniques but as a matter of fact individual hand-knitters might prefer different styles of knitting, just as there are left-and right handed people in the world. The book Knitting for Anarchists by Anna Zilboorg ⁵⁾ is about the struggles of getting away from a one-size-fits-all knitting technique, to alternative ways of producing the exact same structural knit-work. The main issue with Zilboorg's technique is the cognitive overhead for transcribing knitting instructions inside your head.

In the future there may be knitting machines we can't yet imagine. And there is huge potential for collaborative human knitting or crowd crafting. Shane Walter has explored massively parallel human knitting techniques in his Knitting Pieces. Each and every one of those alternative knitting techniques would require rewriting traditional knitting instructions from scratch.

Traditionally cooking receipes have been used as prime examples for sequential algorithms. But the sequential nature of receipes is an artifact of our linear writing system. No professional cook ever cooks sequentially. Cooks always have several pans on the stove.

“Carrot Soup” by Katie Shelly

In fact cookbooks might actually profit a lot if we represented recipes as structural diagrams that show how the meal is composed from individual ingredients and basic cooking operations, leaving the scheduling task to the cook.

Katie Shelly is working on a beautiful diagrammatic cooking book called Picture Cook ⁶⁾ which will be available in October 2013.

You can look at some of her cooking diagrams on her website.

What is true for for the craft of cooking is even more true for other crafts. Let's take a look at crochet patterns in Japanese craft culture:

Knitty Screenshot

Amigurumi patterns are traditionally conveyed as structure, rather than instructions. As a result the pattern is not restricted to any specific kind of crochet technique. It's the task of the human (or a little helpful program like Knitty) to turn structure into instructions.

The fact that patterns from Amigurumi or lace techniques such as tatting are represented in diagrammatic form might be the result of their inherent complexity, which may best be conveyed visually.

But as a side-effect those patterns can be processed in any order the craftswoman wants to. They can be worked inside-out, bottom-up, in groups and circles, using tools and machines that the creator of the pattern would not even imagine in her wildest dreams.

If we want freely exchangeable craft patterns, that defy the Tower-of-Babel effect, if we want to create a playing ground for the future of computational craft, we first and foremost need to specify structural craft-exchange-formats.

By analyzing the details of individual craft techniques, tools and machines, we can then specify how to turn generic structural representations of fabric into instructions for every single technique.

And this is exactly what I aimed at when I developed a computational model of hand-knitting, the model which we will dive right into, in the second part of this series.

I recently got a tweet from a Processing student asking me if I could tell a little bit about myself.

So this is my little Vita, with a focus on how I got into Processing and Computational Craft…

«House of Cards» by Charles and Ray Eames

When I was a kid I spend a lot of time on my own, because my dad was busy being a mathematician and my mom was busy with self-realization following some kind of late 1970s hippie movement.

I grew up playing a lot with LEGO: I could sit for hours building things, that my older brother would then destroy with great pleasure within seconds.

Another childhood toy that I loved very much were slotted cards. Those are basically playing cards with slots on the sides, that can be arranged into all kinds of architectural structures. I recently found out that this toy was created by Charles and Ray Eames, the work of whom I only learned to admire much later.

My parents' style of education was really very anti-authoritarian. I loved to find out things for my self, and even as a grown-up I am mostly self-taught. When I went to school, I was very excited about all the things you could learn, but the teachers got often very angry about the kind of questions I asked.

School can be a little bit boring at times, but I somehow managed to survive spending most of the time drawing doodles on the borders of my notebooks.

I started to like the doodling, and once I finished school, I thought I'd like to become a graphic designer. I created a portfolio with drawings of couples engaging in Tantra-like activities on different types of gymnastic apparatus, such as parallel bars, still rings and the pommel horse. The second part of the portfolio were computer graphics that I had created in Corel Draw.

My application was rejected based on the explanation that my drawings were “adolescent daubery” and that computer drawings are rubbish by definition because you can't see if their creator has any real talent.

Since this didn't work out as planned, I decided to study Media-Technology carried by the hope to somehow conciliate my passions for graphic design and computers. I was very much influenced by Artificial Intelligence and was obsessed by the idea of creating imagery and decorative arts with the computer.

«Borderbuilder» – top and bottom border mode

One thing that I did in school with an early version of Corel-Draw was an ornamental Border-Generator. I was – and still am – deeply impressed by the beauty featured in «The Grammar of Ornament» by Owen Jones.

When I was a student I thought it would be fantastic if websites featured borders that would automatically adapt to the dimensions of the screen. So I created a flexible Border-generator back in 1999 using Javascript and dynamic HTML, effectively creating my first online generative work.

I also created what I called the «Text und Bild Explorer» or simply the «TUBE» – a web page, that would generate drawings using Postscript. The Interface would let you change parameters using menus and a server-side perl-script replaced variables inside the postscript code, rendered it to PDF, and displayed the result in the browser.

You have to know that Postscript is really a fully fledged computer language that is used inside printers and has been a great inspiration to the Processing language. But even though Ben Fry and Chris Reas released the first Version of Processing as early as 2001, I really only got into Processing about 8 years later…

A tool for Interactive Evolutionary Design

In 1999 I realized that Media-Technology was all about Tech, and not as much about human perception as I would have liked. So I also picked up studying Cognitive Science.

I was very fascinated by harnessing natural processes, such as evolution and neural computation for computational design. I created a plugin for a 3D modeling system, that would enable automatic and interactive breeding of transformations for 3D shapes. My biggest inspiration was the thesis of Christian Jacob and the work of Peter Bentley on Evolutionary Design. Both have since published excellent books on those topics, which I highly recommend.

First «rule 110» garment. Model: Sarah Flannery

While studying Cognitive Science, I somehow stumbled upon a course on machine knitting with home knitting machines. Suddenly I realized that there was a possibility to create evolutionary design, that would be available in a world outside the computer, a world that could be accessible to people like my grand-mother, and not just computer-geeks like me.

Then in 2002, I started using Cellular Automata to create patterns on my knitting machine. I presented them at the first «New Kind of Science» workshop in Boston, a workshop that was held by Stephen Wolfram, to promote his idea of a New Kind of Science, based on his book.

To me Wolfram's Book was really just an endless source of knitting patterns, and In my mind a world of Knitting Automata unfolded. I started to wonder if I was alone with my crafty obsession, and started «k2g2» an online community for Knitting Knerds and Geek Girls.

K2g2 turned into a wiki with a craftopedia and a video blog of its own. But even though a couple of people contributed over time, it never really took off, the way I always hoped it would.

In the meantime I was dreaming of a platform allowing people to evolve their own clothes and patterns, using modules that would transform simple patterns into ever more and more complex ones. I knew that those modules had to be programmable using some kind of language that was easily accessible to designers. And this was when I discovered Processing.

My sketches at OpenProcessing.org

I first tried Processing in 2009 and discovered, that even though it is loaded with all the ugliness and awkwardness that is known as «Java», it is really good at keeping the ugly parts hidden away.

I got sucked into the Processing cosmos and found a new home in the OpenProcessing community. I uploaded a couple of sketches and got amazing feedback. People seemed to like what I did, and this felt really good.

When I joined the OpenProcessing community there was a tiny sketch competition that was about getting as much as possible out of 200 chars of code. This was really a good way, to get to know Processing inside out. I loved the spirit; it was both competitive and cooperative at the same time.

But I also love to create sketches that are almost application-like. Little universes, that let the user explore a complex parameter space, using only the mouse and the keyboard. In the beginning I expected the lack of a user interface with buttons and menus to be a show stopper, but I think it really helps to keep the sketch focused, keeping everything clean and simple.

When I began to use Processing, I started the «bit.craft» blog. The original idea was to create little experiments in computational craft, publish them on OpenProcessing, and then write about those on this very blog.

I must admit that I got side-tracked by all kinds of projects, both private and professional. And there was not too much feedback on this blog either, apart from the usual spam-bots. So if there is anyone out there, who cares about computational craft:

Please drop me a line in the comments, and I will promise to share my crafty experiments with all of you!

I recently had the pleasure to collaborate with media artist Ursula Damm on a project called Transits that uses neural networks implemented as OpenGL fragment shaders for generative video processing. The artwork is currently shown in the Sensing Place Exhibition in Basel.

Since Transits is only remotly related to my explorations in computational craft, I decided to host it over at Perceptify.com.

You can now find the Transits Interview on the NeuroVision Page

Identicons are those little icons that are used in forums and blogs to visually identify the persons posting in a discussion thread.

There are services such as Gravatar that allow you to use your own icon across websites, and some sites use a generative process to create identicons for those who don't have one.

Some time ago I designed generative identicons called stitchies, that combine high information density with the simplistic beauty of hungarian cross-stitch patterns. So here are a couple of stitchies generated from the periodic table of elements:

Periodic Table of Stitchies

If every chemical element can have its own stitchy, so can you. Just enter a unique id (such as your email address) into this processing sketch. Your email address is automagically turned into a very much unique pattern — your personal stitchy identicon.

cc-licensed at OpenProcessing.org

Generative identicons usually have a colorful geek chic, which can almost compete with that of rotating GIFs from the glorious days of the early web.

However their anarchic wild-wild-web style does not go along nicely with websites that follow the cult of the Web 2.0, and that's pretty much every professional website these days.

That's where stitchies come to the rescue:

• Unlike other icons, stitchies can easily be color-adjusted to match the design of any website.
• Stitchies work perfectly at even the smallest scale, unlike user photos which often become indiscernible when too small, or distract you from the text when too large.
• Stitchies are essentially two-color QR-codes optimized for the the human brain by taking principles of symmetry and heraldry into account.

I created a stitchy plugin for dokuwiki — the wiki software that powers this very blog and the k2g2 craftopedia — but I haven't found the time to publish the code, so if anyone is interested, please let me know. It's plain PHP, so it can easily be turned into a Wordpress plugin.