From left to right, these represent: LOVE, HATE, HOPE, FEAR, SATISFACTION, RELIEF, FEARS_CONFIRMED, DISAPPOINTMENT, JOY, DISTRESS, HAPPY_FOR, PITY, RESENTMENT, GLOATING, PRIDE, SHAME, GRATIFICATION, REMORSE, ADMIRATION, REPROACH, GRATITUDE, ANGER.

It's primarily based on a set of colours Lina has been working on. She found it useful to group the emotions into positive and negative sets. Something I think is significant is that these colours were made with the colours of the plants and the general feel of the game in mind. I think the problems I found with this exercise was a lack of context - perhaps thinking too abstractly about this is a bad idea.

It's great to see this work being picked up by the Life project by Evan Raskobb at Space Studios - looking forward to seeing more of where they go with this.

I made this chart quickly, deliberately avoiding thinking about potential reasons for my choices. Interestingly I found I needed to start with the motion curves first (which describe how the colours are blended between over time) and these seemed much less arbitrary than the actual colours I chose. The reason could be that there is a closer connection between movement (however simple) and gestural expressions.

First create a program and choose the colours:

Axiom: O
Rule: O => : O O :
Repeat 5 generations

: = Green
0 = Orange

Then "compile" the code to expand the pattern:

1= O
2= : O O :
3= : : O O : : O O : :
4= : : : O O : : O O : : : : O O : : O O : : :
5= : : : : O O : : O O : : : : O O : : O O : : : : : : O O : : O O : : : : O O : : O O : : : :

The resulting weave can be previewed in ASCII as described earlier. This was useful to discover the range of patterns possible. When done, install the compiled code on the loom as a warp thread colour sequence.

Then you follow the same sequence for the weft threads, choosing the colour based on the code generated. In this way you become a mere part of the process yourself.

This is another, more complex program with 2 rules. This expands rather quicker than the last one, so only three generations are required:

Axiom: O
Rule 1: O => O : O :
Rule 2: : => : O :
Run for 3 generations

This technique draws comparisons with Jacquard looms, but obviously it's far simpler as the weave itself is the same, we are only changing between 2 colours (and a human is very much required to do the weaving in this case). However, one of the activities I would have tried with more time available would have been reverse engineering Jacquard woven fabric - to attempt to decode the rules used.

During the workshop it was also suggested that a woven quine may be possible - where the pattern somehow contains the instructions for it's own manufacture.

Some of these patterns when combined with muted colours, have in the past been used as a type of camouflage - and are classified into District Checks for use in hunting in Lowland Scotland. This is, I guess, a kind of less prestigious form of Tartan.

I started off by trying to understand how the patterns emerge, beginning with the basic structure:

The threads running top to bottom are the warp, those running across are the weft. If we consider the top most thread as visible, we can figure out the colours of this small section of weave. A few lines of scheme calculate and print the colours of an arbitrarily sized weave, by using lists of warp and weft as input.

; return warp or weft, dependant on the position
(define (stitch x y warp weft)
  (if (eq? (modulo x 2)
           (modulo y 2))
      warp weft))

; prints out a weaving
(define (weave warp weft)
  (for ((x (in-range 0 (length weft))))
       (for ((y (in-range 0 (length warp))))
            (display (stitch x y
                             (list-ref warp y)
                             (list-ref weft x))))
       (newline)))

I've been visualising the weaves with single characters representing colours for ascii previewing, here are some examples:

(weave '(O O O O O O O) '(: : : : : : : : :))
=>
 O : O : O : O
 : O : O : O :
 O : O : O : O
 : O : O : O :
 O : O : O : O
 : O : O : O :
 O : O : O : O
 : O : O : O :
 O : O : O : O

(weave '(O O : : O O : : O O) '(O : : O O : : O O :))
 =>
 : O : : : O : : : O
 O : : : O : : : O :
 O O O : O O O : O O
 O O : O O O : O O O
 : O : : : O : : : O
 O : : : O : : : O :
 O O O : O O O : O O
 O O : O O O : O O O
 : O : : : O : : : O

This looked quite promising as ascii art, but I didn't really know how it would translate into a textile. I also wanted to look into ways of generating new patterns algorithmically, using formal grammars - this was actually one of the simpler parts of the project. The idea is that you begin with an axiom, or starting state, and do a search replace on it repeatedly following one or more simple rules:

Axiom: O
Rule: O -> :O:O

Generation 1: O
Generation 2: :O:O
Generation 3: ::O:O::O:O
Generation 4: :::O:O::O:O:::O:O::O:O

We can then generate quite complex patterns for the warp and the weft from very small instructions, next I'll show what happens when some of these are translated into real woven fabric...

The trick is to use the fact that we are rendering a CRT TV signal and that you can control what gets rendered in the overscan area (think 8bit loading screens). There is a register which directly sets the background colour of the scanline - this macro is all you need:

#define gs_p_bgcolor        0x120000e0    // Set CRTC background color

#define GS_SET_BGCOLOR(r,g,b) \
            *(volatile unsigned long *)gs_p_bgcolor =    \
        (unsigned long)((r) & 0x000000FF) <<  0 | \
        (unsigned long)((g) & 0x000000FF) <<  8 | \
        (unsigned long)((b) & 0x000000FF) << 16

Which you can use to set the background to green for example:

GS_SET_BGCOLOR(0,255,0);

Its a good idea to change this at different points in your program. When you get a crash the border colour it's frozen with will tell you what area it was last in, allowing you to track down errors.

There is also a nice side effect that this provides a visual profile of your code at the same time. Rendering is synced to the vertical blank - when the CRT laser shoots back to the top of the screen a new frame is started and you have a 50th of a second (PAL) to get everything done. In the screenshot below you can see how the frame time breaks down rendering 9 animated primitives - and why it might be a good idea to use some of these other processors:

I've been invited to do a lecture for Markku Nousiainen's experimental course on computational photography next week, so I've been constructing some demos that display different computer vision algorithms based on the work I've been doing on Lirec. The idea is that they may serve as inspiration for how algorithmic understanding of images can be used for artistic purposes.

The code is part of the mysterious magic squares library.

Today was all about taking the themes from yesterday and making them into concrete game mechanics we can use. We started by mapping out possible constraints imposed by multiplayer activities. We want a large amount of what you do on pluto to be coordinated with other players - and this impacts on the logic of the game world. For instance, doors can be locked - sometimes in a room full of people we only want players who are carrying a key to be able to get through the door, at other times a single player might be able to unlock a door for everyone (perhaps for a limited time).

A locking conundrum.

This sort of play requires a way for players to coordinate with each other, for example using a realtime chat system. A minor crisis involving the details of how to handle this feature was narrowly averted and we escaped to the shores of Ljsselmeer to begin considering the vertical slice, the moustache as core game feature, community service and mandatory fanny packs.