For my conference project, I am further exploring the works of Vera Molnar. She was a pioneer in computer based artwork, having first started by using a plotter. A lot of her works represent or came out of gradualism – modifying the form of something known in very slow ways until it turns into something very unknown, and interesting. I was hooked by her works in which Vera helps a viewer imagine what a plausibly different shape could be. I also appreciated how Vera abstracts away from known legible features in our world (such as handwriting) and studies it with rigor in order to extract the most visually fundamental qualities to handwriting. This is well represented in her 1987 work, Lettres de Ma Mere:
The piece of hers that has been my greatest inspiration in my conference work is Interruptions (1968):
It was easy to get a straight forward replication of Molnar’s work, disregarding the empty patches in her composition. It looked something like:
The lines in the given picture are actually all rotating. After meeting for conference in which we talked about an earlier version of my conference work, I learned that Vera Molnar’s style of work involves thinking of a simple rule and formalizing it. The class made some simple suggestions that should theoretically have some powerful effects for the system. Thus came my first ‘formalized’ rule: adding random length to lines if they were shorter than a certain length:
The next few rules I added modified the rotation of the lines and also the color of the lines. It took me a while to figure out how to randomly assign color to each of the lines independently. While doing this, I certainly learned about the weird quirks of Processing as a library. Even though it intuitively makes sense to color a shape when you create it, you actually have to tell Processing what color to use for this shape every frame. Processing is kind of like an artist who only holds one pen, but draws very very quickly, so it needs to swap pens to draw each line, each time it draws that line. So to fix this, you instead tell the shape to remember what color it should be, and have it set the stroke() color (tell Processing what color pen to pick up) on each iteration of .display(). For the first several implementations of my sketch with the introduction of the new rules, I had coded something so that the color for all the lines was randomly assigned. It took me a while to figure out that I had to tell Processing to change colors in the .display() function of the Line object. Finally I had something that looked like this:
After learning this, I think color really went right in my system. I was able to then modify the color with more control. This also addressed one of the criticisms about my rules when she saw my work in open-studio: my rules were looking too random. The point of gradualism is for the viewers to get some intuitive sense that a systematic rule is at place. I was finally starting to get systems that look more like:
The way color is implemented is very special – it isn’t actually hard-coded into the system. Actually, the system decides for itself what colors to use for its lines (actually each line decides for itself, creating a complex system out of simple individual decisions) , and this part of the program is recursive. A line modifies its color based on the colors in the lines surrounding it. (Specifically, based on the color of the line previous to it in the array.)
Before I talk about what went ‘easy’ or ‘right’ and what went ‘difficultly’ or ‘wrong,’ I want to comment on how there isn’t always a relationship between how easy or hard something is to conceive of, imagine, and see in your head, and how easy or hard it is to code. Some things that sounded or looked simple in the conceptualizing stages were complicated to implement in code, and it also turned out to be simple to implement some seemingly complex concepts / behaviors. For example, It was very easy to populate an array with lines. It was also easy to create a line object. Probably one of my favorite things talked about in a discussion in conference was about the point or goal of our class, which is to enable students to see visual work and feel encouraged and confident to be able to replicate it in code, or to execute one of their own imagined ideas.
For starters: I was not able to get as much visible interactivity in my system as I had hoped. In some ways, it still looks random. And in other ways, it does not look random enough. Some of this has to do with how many exact rules are turned on at a given time. Being able to set a randomSeed and to toggle the frameRate of my system have been very helpful, because it has allowed me to see what would happen to my system over time in more controlled settings. Even with all the rules turned on at once, it is easy to see with accelerated frameRate that my system seems to fall back into a mostly regular loop. That does not mean that it is not mesmerizing to look at – it definitely is, especially when you realize it is a simple system of only Line objects.
My class suggested writing my system with a randomSeed in place. This also turned out to be a lot easier than I expected or was familiar with from my previous coding experiences.
For randomSeed, I had to learn that a random number generator essentially is “only random on the outside”: inside, it deterministically creates numbers based on the given seed. So the specific sequence of numbers that it will return from the seed ’99’ is always the exact same sequence, regardless of how many times we run it. That’s why it’s called the ‘seed’: ALL of the randomness grows out of just that initial seed, like how an entire tree grows out of a seed.
I will definitely continue to work on my sketch, specifically in trying to make interaction and gradualism more apparent.
