Central Park series: data-driven artwork

In this small series, I worked with the axidraw pen plotter and Processing to imagine the new growth happening in early spring in Central Park.

From the warmth of my room, I researched March weather data in Central Park as well as geotagged posts of spring flowers, outsourcing my reference-gathering to the data of others.

I made some simple plots of the weather data using Processing, comparing humidity and temperature by date and plotting the points as small circles.

Cloud cover was additionally represented by adding rings around the circles (the rule was to add one extra ring if cloud cover was between 30% and 60%, two if it was anything over 60%).

With the axidraw, I could then draw the plots accurately and precisely using waterproof artist’s pen directly onto watercolor paper.

I drew lines to create dimensional relationships between the data points, and then “grew” the flowers I’d been researching from home out of the spaces between the data points.

The data formed a “garden” to situate the flowers, and their pattern was dependent on its form, as with the growth anticipated in the season.

The data forms them and gives a structure to their layout, just like the forces represented by that data enable the form of our gardens year over year.

Aleataxonomy series

“Aleataxonomy”, my shorthand from “aleatoric” (created from random action) and “taxonomy” (referring to the classification of the elements I use in drawings), is a recent series based specifically on limiting drawings to randomly-generated numbers of elements in sequence. The project takes on the problem of end condition, or “when is the drawing done”, that I’ve been dealing with since working on series like Schema (one of the first that departed from my historic end condition of “whenever the pattern goes to the edge”). My hypothesis was that even with an artificial end condition, these drawings wouldn’t end up looking unfinished because of the conscious and subconscious aesthetic evaluation I unavoidably engage in as I draw.

Procedurally, I would first figure out what types of patterns would work for this process, break down their individual procedures into steps and ranges, and then write up a script in Processing that would render out random values (within the range) each time it ran.

For some of these processes I made intermediate sketches to determine how I should balance out the ranges of values before I could write the randomizing script.

Once I had a solid idea of the steps and ranges of values, I wrote scripts that would choose a random number from a range for each step and, critically, read the choices back to me in clear step-by-step instructions. Much of “aleatoric” art has to do with physical randomization tools like dice, but since I had access to coding text output and random value generation in Processing, that made it possible to write custom ranges in absolutely whatever value I might want.

Once I had the readout, my task was to follow the instructions to the letter (often using tally marks on scratch paper to record how many of each mark I’d completed).

– Example of a first step. The result of the Processing “dice roll” is at the bottom of the black rectangle below the code. (For those following along at home, the code that requests that printout is println())

– Process for a full drawing

There are many ways I can take this kind of process. One of the options I wanted to pursue was to try using the same exact values to make multiple drawings. Would they be the same, indistinguishable, or somewhere in the middle?

One of the unexpected upshots of this project was learning just how many houses or lines I might be able to draw in a small space without realizing. Even when I was dealing with scales like 6”x8” and large numbers like 150-250, it turns out that’s barely enough “house” marks to look inhabited.

In general, I’m glad I indulged this impetus to take programmatic drawing to a bit of an extreme. It’s another tool I can use to determine when a piece is “finished”; it allowed me to explore aesthetic balances that I might not have chosen to work with before; and in a way it gives me more confidence in the persistence of my artistic style.

Processing sketches

One of my many goals this year has been to learn more about scripting and procedurally generating graphics, for which I’ve been using the language Processing. I don’t have a lot of prior experience with code, though, and that makes things a bit difficult!

It’s a totally different way of thinking. Processes that seem simple enough to me—like drawing a series of city blocks that are different shapes but all have the same width streets between them, for instance—are surprisingly difficult to put into code. And at the same time, graphics that would be difficult or just tiresome for me to execute physically, like filling the screen with parallel lines or drawing the same shape over and over in different places, are particularly simple.
Much of the learning curve has just been differentiating between the different parts of code and learning their names so I can understand instruction, even before I learn the actual functions.

That all said, I’ve been having a pretty good time coming up with little visual programs. Below are some short animations that I’ve made so far. I’m particularly proud of the fact that I came up with and wrote all the code for each one myself. It’s possible to copy others’ code, but I find that that often causes more problems than it solves—and it’s more satisfying to know I coded something from scratch.