12 October 2012

30 Pick up the pieces, put them back differently

Following a discussion at a supervisory meeting, I've decided to hang the coding I do on a particular range of behavioural modelling: flocking, swarms and attraction/repulsion. There are some very pragmatic reasons for doing this, such as the fact that it's less explored by designers than say, evolutionary art or modelling natural form*. There are some less pragmatic ones too. Firstly,  a rural childhood that may be part of the reason I'd generally rather watch birds flocking than most television. I do my best not to be superstitious, but catching sight of flocks of birds in the evening does appear to be a good omen whenever I've been making big decisions. In the very unlikely event that I'm ever on Desert Island Discs, a daily murmuration of starlings going to roost would be my luxury. Secondly, Chris Reynolds' Boids simulation, which is one of my longest standing web browser bookmarks, and probably a good example of how if things bump around in your brain for long enough, you find a use for them. Finally, as I start to compile a definition of terms, the fact that flocking means something entirely different in the world of printed textiles (what some people might call curry house wallpaper).
This has meant letting go of the models I've been using to structure my code so far and taking the plunge with Object Oriented Programming. Unlike my previous attempts, which I've been able to do by essentially mapping existing (if extraordinarily rusty) coding or mathematical skills on Processing, this has involved learning how to work in a new way. Simply put, the elements that make up the designs will be the Objects; their arrangement will be determined by code (in programming terms, the Methods in the Object's Class). Unlike the work so far, where I'm been able to get to the bit where I actually have some kind of visual output fairly quickly, this will take longer - so apologies for the lack of an image. You could watch this.
Been a while.
*or that my Director of Studies suggested it.

4 May 2012

29 Repeatless 0002: Noah Sateen v002 (Hellibore)

Title: Repeatless 0002: Noah Sateen v002 (Hellibore)
Size: Three sections shown; top is 3760px x 3760px, middle is 1400px x 1400px, bottom is 600px x 600px
Method: Processing
This is essentially the same code as the previous post, but using more considered imagery in an attempt to get the design to look more beautiful (or at least locate it more firmly in the context of printed textile design).
There are three layers* to the image: a little block of dots goes on first, randomly coloured to a set palette, then a randomly sized and rotated image of a Hellibore flower (using the cellular automata derived positioning code as the previous post) and finally a modular circle pattern. The flowers are set to a transparency proportional to their size - the smaller they are, the more opaque the setting. This is intended to try and prevent any one flower from standing out too much. In a traditional repeat design, the designer would seek to try and make the imagery as balanced as possible - that is, prevent any one element from dominating and hence making the repeat easy to spot. Even though the design above doesn't repeat, I think it's important that a notion of balance is achieved.
I've attempted to create the image using a similar method as if I was working on an actual design brief. The spots and the circles are there to that end; they don't use the cellular automata code and feature purely to make the design look good**. The randomness settings have been tweaked to try and get a plausible (in commercial terms) design. I spent far longer tweaking the parameters to get a visual result that I was at least vaguely happy with than I did actually adapting the code to work with the new imagery. (I'm writing this a week later, and do feel a bit happier with the outcome that a week ago, when I thought it was a bit rubbish.)
This process raises loads of questions about the degree of control (and hence the complexity of the code, or at least, the time to fiddle with it) required to get a successful design. For example, in the bottom image above, the large flower towards the bottom left has a leaf and a petal that both have a horizontal edge. In repeat print terms, this is (generally) anathema; part of the trick of avoiding the repeat being noticeable is to ensure that there are no strong horizontals. Does this remain a consideration in a repeatless design? If so, then code needs to be developed to detect if this is happening, and if so, rotate the element as necessary.
Another question that has arisen is to do with the value of the cellular automata model. In the images above, the images worked better visually with the flowers set to up to 4 times the cell size; this rather negates the point of the model in the first place which is to ensure the elements aren't too close together - if two large images (that fill up to 16 cells each) are placed fairly close together, they may still overlap. Of course, the code could be rewritten to avoid this***, but should the imagery have been altered in a different way to ensure the model is adhered too?
Whilst the structure of the designs above is generative, the content is not - there's a library of 23 hellibore photos, 30 circles and 7 spots that the code randomly draws upon. One of the planned outcomes of this project is to develop some kind of interface that allows designers with no coding experience to develop repeatless designs. Whilst I am interested in developing some designs that are entriely generative, it will be important to create code that does work with existing imagery if the experience is to be shared.
*I'm trying to avoid working as if I'm in Photoshop, but the nomenclature sticks...
**I realise that this is in the eye of the beholder, but without making any great claims for my aesthetic judgement, I'd hope that having done this professionally for some time gives me some kind of perspective borne out of experience.
***In programming terms, the next thing I'm aiming to get to grips with is code that responds to what's already in the image, not just that places it to an initially fixed set of conditions. 

20 April 2012

28 Repeatless 0002: Noah Sateen v001

Title: Repeatless 0002: Noah Sateen v001
Size: 400px x 800px (snapshots of two runs shown)
Method: Processing
Two images (chosen at random from 11 files created in Photoshop) are placed in random positions in each row of a 20 column design, at least 8 cells apart. Each image cannot have another image in the same column below it for 5 subsequent rows or in the cells diagonally below it for 1 subsequent row.
It feels like I'm getting to grips with Processing now. After a wasted few hours trying to adapt the Ten Cell Sateen code to do this, I started again from scratch. Short term pain, long term gain. The new code uses functions, so the bit that loops is only a few lines long. I've used Arrays (rather than ArrayLists); there was a bit of code I had been using that I'd found on a forum - it worked, but I didn't undertand why and that annoyed me. This prompted me to find a different way of using Arrays, which has resulted in (hopefully) much better way of doing it (and one I fully understand). I'm trying to make the code as modular as possible, prompted by a discussion with my supervisory team.
The images that Photoshop chooses I created very quickly, really just to check everything was working. I'm really happy with the code, but when I starting this project I was determined that the designs I created would (as far as possible) look beautiful and not just be interesting. I don't thing the images above meet that criteria. There's a big sense of achievement in getting the code running as planned, but the content falls into the interesting-not-beautiful catagory. I'm pleased with it, but I doubt it would have much interest in a professional design context.
This highlights another area to explore - how the content is created. It could be made in advance (as with the above), generated by the code or a combination of the two. I'm interested in all of these; the first of the three could allow designers without coding knowledge to generate repeatless pattern.

23 March 2012

27 Video of presentation

I did a short presentation a couple of days ago at a meeting of CODE Creatives (a gathering of Manchester Metropolitan Univeristy staff and post-graduate researchers interested in the use of code based design). You can see me waving my arms about and wearing a loud shirt here*. The presentation is very much based on the abstract I wrote to help structure my formal PhD proposal (the RD1).
*I almost always do both.

26 Repeatless 0001: Ten Cell Sateen v005

Repeatless0001_TenCellSateen005a Repeatless0001_TenCellSateen005, Animated gif of Processing code running 200 times
Title: Repeatless 0001: Ten Cell Sateen v005
Size: 200px x 800px (two 200px x 200px section shown)
Method: Processing / Photoshop
This is a new version of the same cellular automata model as posts 23 to 25 (including the rotate of post 25). However, this version looks to model something else as well; how the design would look as if it was coming out of a digital printer.
The code is my first foray into writing code that runs continuously in Processing. It took a while to get the hang of how to do this*. The bit where the image is added ended up being simpler that the previous versions; it is always added in the row at the top of the image and the animation moves it down.
The code runs indefinitely, but saves the first 200 cycles as an image. The images show two runs, each run made into an animated GIF in Photoshop.

*Note to self: You're learning how to do something new. It will be difficult. Other people don't care.

16 March 2012

25 Repeatless 0001: Ten Cell Sateen v004

Title: Repeatless 0001: Ten Cell Sateen v004
Size: 800px x 800px (four runs shown)
Method: Processing
A new version of the previous post. This rotates each cell image by a random amount. Sateen repeats (definition at the end of this post) are generally multidirectional*, so this random rotation is intended to create the suggestion that the resulting image could be viewed from any angle.
I've solved the problems with how to handle the rotate described in the last post. Rather than Layers and Free Transforms, I'm now thinking in terms of co-ordinate matrices and stacks...

*A multidirectional repeat is one that works when viewed from any angle – in other words, it has no noticeable top, bottom, left or right. (This is normally achieved by rotating the elements that make up the design to a variety of different angles.) Favoured by cost-conscious manufacturers because pattern blocks can be placed anywhere and at any angle on the fabric – that is, packed together to achieve as little wastage as possible.

24 Repeatless 0001: Ten Cell Sateen v003

Title: Repeatless 0001: Ten Cell Sateen v003
Size: 800px x 800px (four runs shown)
Method: Processing
This is the same basic cellular automata model as the previous two posts (22 and 23), but the code loads a small image (the quartered circle), instead of filling the cell with black. (The colours are taken from an old design of mine.)
The next step is to work out a way of rotating the individual images randomly. My initial attempts to do this don't work and have highlighted the effect that working with a particular bit of software over long periods of time can have. I'm so used to working with Photoshop®, I assume that anything "pasted" into an image will be on it's own new Layer and if it is rotated, it will by default rotate around its centre. Coding in Processing means working with image content in a completely different way; I realise how Photoshop®'s Layers and Free Transform function have entrenched the way I think of moving stuff around.

9 March 2012

23 Repeatless 0001: Ten Cell Sateen v002

Title: Repeatless 0001: Ten Cell Sateen v002
Size: 100px x 400px (four runs shown)
Method: Processing
The next version of the process started in previous post. The code randomly places a 10px x 10px black cell in one 10px column of each 10px row but not in the same column as any of the previous 5 cells. The intention here is to use a cellular automata model to create a sateen-style pattern (there's a definition of sateen repeat at the end of a previous post). A cell cannot go black unless the five cells above it are clear.
The coding is done with a couple of one-dimensional arrays. The first holds the positions a black cell could occupy (those with five or more empty cells above) and the second has the positions that cannot be used (because there are four or less empty cells above it). As each row gets its new black cell, both arrays update to reflect the subsequent row's black cell possibilities.
The code operates on a similar principle to the code in the Gordon image, although it was written from scratch in order to develop my Processing skills. I'm dipping into Reas, C; Fry, B (2007) (1) and the Processing website to do this. Getting info on using the ArrayList command was tricky; the Array command's Functions seem too basic (but I could be missing something) and I missed the posibilities of arrays in Javascript. At some point, I think using two dimensional arrays will offer a more elegant way of coding, but I did a bit of research into Turing machines as part of this and found it useful to think of a one-dimensional array as the tape in such an idea model.
(1) Reas, C; Fry, B (2007) Processing: a programming handbook for visual designers and artists The MIT Press, Cambridge (Massachusetts)

22 Repeatless 0001: Ten Cell Sateen v001

Title: Repeatless 0001: Ten Cell Sateen v001
Size: 100px x 400px (four runs shown)
Method: Processing
First attempt at working with Processing. The code randomly places a 10px x 10px black cell in one 10px column of each 10px row of a 100px by 400px workspace.
This is the initial step in creating code that does a similar thing in Processing to what the Gordon code did in ExtendScript / Javascript for Photoshop.

24 February 2012


Repeatless is now a (part-time) PhD at MIRIAD, the Art and Design Research centre of Manchester Metropolitan University.

It has a title:
How can digital technology be used to apply novel methods to the creation and production of printed textiles and surface pattern design?

This abstract describes how I think it will develop:
Pre-digital textile printing technologies used in mass production mechanically transfer the same design repeatedly down the entire length of the substrate. The patterns they reproduce have to loop identically and cannot be altered without stopping and reconfiguring the printer.
Two proposals are made. Firstly, that digital technology could allow a design to change as it is being printed. A digital printer could be receiving constantly evolving information, producing pattern that need never do the same thing twice. Other disciplines within the creative industries such as architecture and graphics have established areas of practice where generative systems are used to create design outcomes. Whilst there has been some research into this field in printed textiles and surface pattern, it remains undeveloped.
It is therefore secondly proposed that generative systems be used to create evolving pattern. These might model complex systems, respond to external intervention / interaction or re-interpret existing textile aesthetics. The generated patterns could then be digitally printed on fabric or other substrates, producing outcomes that demonstrate the application of novel design methods.

(Future posts will revert to having images.)