On Generative Art

The Long and the Short of It

Generative art has a long history. The basic idea is to create systems, processes, or sets of rules that can be put into motion to create art, rather than creating it directly. Sometimes, part of the goal is to add some randomness to the algorithm, so that each run creates something unique. Some examples continuously morph, never stopping for long on any one iteration. The art being created–or generated–is often visual art, but other sorts are possible. Music is of particular interest to me.

Wind chimes, comes to think of it, are a pretty good example of a certain sort of generative music. You cut the tubes to lengths so they’re part of a scale or arpeggio (perhaps more than one), and set them so that the wind plays them. You choose the material of both the tubes and the striker, both of which impart a quality to the sound created. And the wind creates the random–or so complicated as to be indistinguishable from random–element.

Programming computers to create art is both a fun way to teach programming and a fun thing to do with programming skills as you acquire them. The symbiotic relationship between creating a learning is as true with code as it is with any other art. If you’re of an artistic bent and have any interest in programming and/or game development, you can’t go wrong with q5.js and p5play, both of which are libraries for JavaScript that take a lot of the pain out of creating graphics. p5.js, the inspiration for q5.js is likely the most popular option, and still a good one. It’s easy to load any of these libraries into CodePen (or similar) and start creating.

That’s the executive summary. What follows is the longer story.

Beginnings

When I first got into programming computers for fun, in Atari BASIC, among the first things I build were drum machines. On the Atari 400, I wrote a few different types of these. The first were instruments, played in realtime via the keyboard. The second were sequencers, where the application played a set of patterns repeatedly.

And, yeah, I’m old as dirt.

Flash forward a lot of years and I discovered Ableton Live‘s “Follow Actions,” which let you set up musical phrases (“clips,” in Live lingo) to be played sequentially or at random. By setting up a variety of bass lines, guitar parts, keyboard parts, and drum loops, you could create random music that goes on forever.

I’ve always found the idea of algorithmically generated art fascinating. I’ve mostly been interested in using it to generate music, but there’s a far larger group of people who use it to generate visual art.

Processing, and its Discontents

The idea of generative art got a huge boost in 2001, when Casey Reas (Wikipedia | Homepage) and Ben Fry (Wikipedia | Homepage) created Processing (Wikipedia | GitHub), a programming platform designed to simplify creating art with code. Both Reas and Fry had interests in art, programming, and education. That’ll be a recurrent feature in the history of what they started. Processing ran on Java and used a simplified Java syntax along with a minimalist programming environment to make it easy for non programmers and beginning programers to create scripts that created visual art (“sketches” in Processing lingo).

I downloaded Processing back in the day and enjoyed playing around with it. I even blogged about it at the time (2011). Fry and Reas made good on their goal. Creating art in Processing was easy and fun.

There’s a rule of the programming universe called Atwood’s Law which holds that “any application that can be written in JavaScript, will eventually be written in JavaScript.” For a brief window of time, there was Processing.js. This project ported Processing to JavaScript. This meant you could run it in a web browser. You didn’t have to download anything. You didn’t have to deal with desktop Java or any of the various, doomed efforts to run Java in a web browser. But you still got to created in the simplified Processing syntax.

John Resig (Wikipedia | Homepage), the author of Processing.js, is more famous for creating jQuery, a JavaScript library once a part of every web developer’s toolkit and is still widely used. jQuery made doing things in JavaScript easier and ensured they worked well in different web browsers and on different platforms. This was really crucial in the days when JavaScript was fairly fragmented and getting a script you’d labored over to work well in different browsers made web programming incredibly frustrating. These days, Resig is Chief Software Architect for Kahn Academy.

Resig mothballed Processing.js, but Lauren McCarthy (Wikipedia | Homepage) ran with the idea and created p5.js in 2013. McCarthy, like her predecessors, maintained and extended the the basic idea that runs through all these iterations: an easy-to-use platform for using code to generate art which also functions as a platform to learn programming. As before, learning and creation–in fact, learning through creation–were joined.

Here’s where things get interesting, politically. Back in 2012, Fry, Reas, and a third partner, Dan Shiffman (Wikipedia | Homepage), created The Processing Foundation to keep Processing–now as p5.js–alive and promote it. Ben stepped down from the board of directors in 2023. That’s rarely a good thing. Fry outlined his reasons on his social media accounts. In his October 4, 2023 Mastodon post, he calls The Processing Foundation to task for spending too much money on promotion and outreach and not enough on software development. But Reas and Shiffman, in their own social media posts, have stood by The Processing Foundation. Lauren McCarthy’s comments were harder to parse, but included “I can’t engage with his lies here on twitter.”

I’m not sure whose side to take in this conflict, since there’s not much to go on. Personally, I respect the programming chops of each of them.

One Way Forward

Just before the big shakeup at The Processing Foundation, Quinton Ashley, yet another programmer/educator, created p5play in 2021. p5play is a platform originally built on top of p5.js for creating video games. However, frustrated with how things shook out at The Processing Foundation, Quinton decided to port the essential bits of p5.js to create his own q5.js, which he considers a “sequel” to its inspiration. He has plans to eventually rebrand p5play as q5play.

(Ashley got his start on q5.js by forking Ling Dong‘s dormant q5xjs project, which was an effort to create a more efficient p5.js.)

p5.js is very much alive. But, given how impressed I currently am with Ashley’s efforts to improve and extend it, I’m going to focus on q5.js and p5play for the moment, and fall back to p5.js if that doesn’t pan out.

Credits

The featured image for this posts is a a detail of a screenshot from Shimmering Mosaics by Claudio Esperança via OpenProcessing.