Creative processing

Most visual designers swear by Processing as a tool, partly because it’s considerably more accessible than heavyduty programming languages. “Everyone can learn it: it only takes a few hours to start writing programs,” says Reas, who should know – he co-developed the language with Ben Fry, and the pair have since published various books on how to use it effectively in design projects.

“While learning C++ with no prior programming knowledge is quite difficult, Processing is a breeze,” agrees McWilliams, who also recently co-authored a book with Reas, entitled Form+Code in Design, Art, and Architecture. “With developments like Processing.js, it’s getting even easier. Increasing numbers of designers have already picked up some JavaScript, and Processing.js adds one more arrow to that formidable quiver of design tools that rely on the same underlying language.”

Besides Processing, Dr Woohoo includes XCode and openFrameworks in his arsenal, and also Cinder, Quartz Composer, ExtendScript and ActionScript when required. His creative process varies according to the application: for immersive, experiential art installations, he often creates a server application to process and analyse the data and modify the visuals or audio on the fly. It might be developed from scratch, build on a previous project, or take advantage of open-source code.

So how accessible is this field really to the average designer? “If you prefer not to code, but play with generative applications to help enhance the creative process, it could be something as simple as a plugin for Illustrator or Photoshop,” says Dr Woohoo. “For those who are a little more adventurous, ExtendScript is Adobe’s customised version of JavaScript. Processing follows closely, because its language is so natural, without the kind of rules that can be cumbersome to designers.”

On the plus side, unlike in the late 90s, cost is no real barrier to entry: “Much of the software is free,” observes Whitelaw. “The challenge is the code-literacy required, but there has never been a better time to learn to code as an artist or designer. The resources and community out there are amazing.”

The fact that he’s entirely self-taught leads McWilliams to believe that coding, per se, isn’t that hard to get to grips with: it really depends what you want to do with it. “What’s hard is the syntax – but that can be looked up – and the techniques and strategies for creating a project,” he suggests. “Those last two are certainly harder and need to grow with experience. Thanks to open-source projects, openprocessing.org and many great books on the topic, there are tons of sample programs out there that can be picked apart and modified.”

Of course, as a lecturer he has plenty of experience passing his knowledge on: “I always say to my students: when learning to program, remember that it’s a language,” he reveals. “Much like any other language, it helps to focus on reading as well as writing. Folks typically jump into programming and just try to write something right out of the gate without looking at code as something that is read, by humans, as well.”

More often than not, generative artists will learn what’s required to tackle the job at hand, and evolve and expand their knowledge this way, rather than attempting to study programming in more general, abstract terms. “It means my understanding is never complete and I’m always learning, but that’s actually part of the fun,” adds Whitelaw. “The challenges are often more conceptual than technical: the hard part is getting the idea right.”

Accordingly, one of his pet hates is the limited range of generative techniques that are recycled by lazy designers: “Voronoi subdivision and Perlin noise get used over and over with just a few tweaks,” he frowns. “My advice? Do it yourself, from scratch. Make a system that’s weird and idiosyncratic, but that you understand from top to bottom, or take an existing system and hack it until it’s unrecognisable. That’s when the fun starts.”