Iterations of a Lissajous Curve Generator
In between working on other (far more vexing) problems I have been tweaking a somewhat simpler Processing sketch. Some months ago I watched Brendan Dawes’ talk at TEDx Manchester in which he uses Lissajous curves to get at the value of iteration in design. Dawes’ larger point is certainly well made, but I was also attracted to the Lissajous curve itself. I started trying to write my own generator, and have gone through several versions before landing at the current one.
I’m unable to embed the sketch file itself due to security restrictions here, but I did capture an earlier version in the video below. The sketch itself is posted over on OpenProcessing.
There are several qualities to this effort that I find compelling. On a visceral level, watching the curve appear is soothing. The three competing rhythms of horizontal motion, vertical motion, and the changing colors overlap in a way that is mesmerizing. Eventually the three would repeat themselves, but that would take an incredibly long time.
Intellectually, I appreciate the iterations involved in working towards this state. The rhythm of writing code, testing it, tweaking it, and re-testing is soothing – particularly when there isn’t a specification for the finished product. You watch carefully as the results of each version play themselves out, and start plucking at different parts of the code to see what changes. There is even a symmetry between this effort and the one that Dawes talks about. Who knows – the next tweak I make could result in everything falling into place, but at a certain point you have to commit to the process being done, to the choices you’ve made thus far.
I remember, very clearly, one of my professors in grad school saying that one of the problems that comes with the use of computers in a design project is that they substitute “evaluating alternatives” for “making choices.” His argument was that when drawings were made by ink on mylar, every line you drew brought with it a certain commitment. If you drew a line wrong, that line then had to be accommodated in your design proposal – so choose carefully. With the computer, however, the need to commit is reduced as the easy of backtracking increases.
The argument is flawed, however. In describing design as a series of choices that are revised at great cost, the iterative process is lost. In code, as in architecture, I believe it is better to quickly cycle between production and evaluation, from designer to critic. Choices must still be made, but not _every_ action needs to be a choice; there is space to allow a process to churn for a while, then to call a halt and move to the next phase.
Of course, in a well-structured process even a quick iterative cycle is too restrictive; the designer (or design team) should be working toward several competing alternatives. These can then be evaluated against each other, and grafted or pruned in an attempt to find the right mixture of individual elements. While I can’t say I do this in a project like the Lissajous generator, this is only one of several sketches that I work on simultaneously. Each offers different challenges, and the techniques I put in place for one sketch can frequently be re-used in others. The change in context between different projects can help me maintain a healthy critical distance between myself and any project, as well as between myself and the language in which I am coding.