More selected projects

Threads.

In this report I will reflect upon textural metaphor in computing, network as netting, and the grace of functions. I will consider where these ideas meet and what happens in this meeting. I will use a couple of recent projects I have worked on in the past year as a cast-on into these ideas and attempt to understand something about the environment we live in.


produced by: Isaac Clarke

An ancient metaphor: thought is a thread, and the raconteur is a spinner of yarns - but the true storyteller, the poet, is a weaver. The scribes made this old and audible abstraction into a new and visible fact. After long practice, their work took on such an even, flexible texture that they called the written pager a textus, which means cloth.
-Robert Bringhurst, The Elements of Typographic Style [1]

Recently I have been reflecting upon the work I have made over the past few months, looking for the threads running between projects and assignments, in an attempt to tie up loose ends and see the forms of my thoughts. I have found myself caught up in textural metaphor that exists in computing.

We work with pattern making machines, our computers using a form of logic not far from the looms that were their previous technological form. We layer up these patterns in various arrangements with some becoming so complex we could wait many lifetimes to see them repeat. On top of these switches we build languages that extend the material language into mental models that we use to structure our databases and manage our own movement, they reflect back to us how we think (or how we think we think). We continue to talk about processor threads, interlaced video, meshes, and net-works. I have been wondering what the constraints of this language are and if it is something to be embraced or resisted. Should my programming mimic the processes of spinning and weaving and manipulating threads, are these processes wound so tightly into the machines that they can’t be escaped?

I have found that my approach to making computational art is to make tools with which I can play. When you write a program, you write instructions of what you want to happen. I find this makes it very difficult to stumble upon something that is novel. Making tools pushes you back a layer, where you can then play and find unexpected relationships and translations. I have observed other artists using this approach too such as the unity tools developed by Fernando Ramallo [2] for David Kanaga’s Oikospiel [3], which allowed him to play his game into its final form rather than programming it. 

(Below: Kanaga's Unity Tools for Oikospiel)

 

I have taken this idea over the past few months and created a couple of tools which have been helpful for me to play through understanding some of the textural metaphor of programming. These two programs are QuipuMaker and BraidLab. Quipu is a form of knot-notation mostly used by the Inca Empire [4] in the 17th century for various reasons, some known and some lost. Using a base 10 number system in combination with colour, knot direction, and thickness of cords, they were able to densely pack information into the threads. The descriptions of Quipu remind me of modern databases, with branches of information extending from each other, holding numeric references to physical events and objects. QuipuMaker [5] is a program which takes a text file as input and outputs a diagram for knotting a quipu, as a way of giving data a closer physical form, to be held in your hand and turned over, referenced, and counted. Like a cross between a rosary and an abacus.

 

The second program, BraidLab [6], was developed to create 3D models of braids. I used tiled diagrams of crossings as the cells for a version of Conway’s Game of Life[7], this gave me a way of combining functional and emergent processes, the result is a structure made from the paths of cellular movement. Entangled threads of logical locomotion.

 

Both of these programs offered me ways of understanding and interpreting the relationship notation has to physical form. That final form they both have is stillness, it is a memory, it is a fixed state. This is in contrast to the programs themselves which are in motion, the code is paths to follow that bring me closer to the thing I am wanting to look at. I have found that these tools of translation I have been working on have become more interesting than their output. They speak in their operation, performing the formation of returning their values.

This raises questions about the structure of the code itself. Is it a script or a score? Is my feeling that the code performs itself accurate? If I was to create a program that gave the same output but using a different programming paradigm, a different underlying structure, then would I feel differently about the program? I could see how a functional program, with fixed state, could appear more score-like than an object-oriented program. Do these paradigms offer different affective qualities to the programmer?

In his book Speculative Grace (2013) [8] the theologian Adam Miller tasks himself with “porting” grace into an “object-oriented theology”. Miller asks himself “can grace survive such a port? Would it remain recognizable? Would it still be functional?”(Miller, 2013, p.5). I began thinking of my programs and code with Millers questions in mind. I am interested in seeing how the program may hold other things than what I have coded, what qualities they may have entwined within them that have been left as traces of the network. BraidLab and Quipu Maker can be seen as tools of translation, from ASCII text to Knots and from cell growth pattern to Braids. With reference to actor-network theory Miller talks about translation and how we align objects to one another:
 “Translation is necessary because objects resist transparent reduction. Translation is possible because objects, composed of and shaped by other objects, are available. Because objects resist, detours are required. Because objects are available, intimacy is unavoidable”. (Miller, 2013, p.59)
I have found this term intimate detour an effective way of describing what is happening in artworks and perhaps it also follows into the code itself. There are things that are indescribable, and we attempt to describe them. There are thoughts with no form that we sculpt. Miller comes to define grace as having two faces; of work and suffering. He goes on to suggest all objects have properties of resistance and availability which determine their presence and their interaction with other objects. It is in this presence of objects amongst objects that grace can be placed.

Thinking of Millers suggestions are we able to find grace in a program? Could we analyse the resistance and availability of a function? What would that look like?

 

I suggest we begin our search here, in the first line, at the arguments for the function. Here we are told what the function needs in order for it to run. If we call upon the function without these values it will resist us, acceptable arguments of the correct type allow the other lines to be read/executed/acted/performed. The program suffers the work in the material exchange happening hidden down in the threads of processing and memory. Code can be direct, or the code itself can detour. It may loop inside itself recursively or take a longer path to the same solution. In our un-optimised structures extra work is done, burdens carried, decisions made, and memories stored. It seems that the code could be full of grace.

As well as asking for something to happen the code can listen for events and it can respond to changes in its environment. It is happening now as I write, I press down on a switch and a letter is pushed through layers of operations and placed into this string. It seems as though there is no beginning or end, it is there waiting, listening. But code can only hear what it knows about. It can only hear certain sounds of certain types. It can only respond to accepted arguments. It appears that code doesn’t improvise but follows the script/score exactly. Code isn’t an intermediary as it impacts events so it should not be ignored, but the outputs are often predictable. Code has a role in handling memory that is important to the network. When a program runs it decided what to keep and what to replace, it brings processes to an end as it initialises new action.

In the essay Bringing Things to Life: Creative Entanglements in a World of Materials (2010)[9], Tim Ingold offers an alternate translation of actor-network from the original French acteur-réseau.
“But réseau can refer as well to netting as to network – to woven fabric, the tracery of lace, the plexus of the nervous system or the web of the spider.”(Ingold, 2010, p.12)
This suggestions of taking a different translation has the impact of changing how we might imagine the connections between actors. The network turned into netting allows it to be seen as “lines of becoming” and “conditions of possibility”. The image of network “goes from point to point, in sequence, as quickly as possible, and in principle in no time at all, for every successive destination is already fixed prior to setting out”(Ingold, 2007, p.75)[10] It is an articulated body, it is in its final form and like the output of a program it is still, it is only memory, it has been executed. Losing that image of straight lines connected to static nodes, and replacing it with paths of possible movement, the acteur-réseau comes alive and it becomes environment

(below: a diagram of a social network from the wikipedia page on actor-network theory and my diagrams comparing a static memory of a network, and a netting/knotting of paths in an environment.)