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.

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.

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 1) and critically 2) 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”3) 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”4) 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.

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 5) 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 6) which will be available in October 2013.

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.

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.

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…

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.

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.

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.

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:

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.

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.

1)
All examples are open source. Most code snippets are developed in Processing and hosted at openprocessing - the Flickr of computational art.
If you have created a Processing sketch for computational craft, or use our code or algorithms in one of your projects, please let us know, so we can feature it here at BIT.CRAFT