Risto A. Paju
algorithmic art

rants

Contents

On technology
On style and subject
On political art
On giving credit
Open source software
    Workshop code

On technology

In 2017, I was planning to submit a paper on my OpenGL methods for publication. One of the most memorable reviews I got said:

"Artists need not learn how to do GPU programming. Higher level languages and programming environments shield the artist from this tedious lower level."
Another reviewer also mentioned that tools like Processing may use OpenGL behind the scenes. Well, I did have a look at Processing when I was starting my live demos in 2016, and it could not do render-to-texture, i.e. no iterated GPU work.

In general, I absolutely believe that artists should make their own tools whenever feasible. Past masters were known to make their own dyes, for example. To me it is all about making your own thing, vs. turning the knobs on a system someone else designed.

Moreover, I want to understand what is going on in my work. I sometimes get interesting results from coding mistakes, and then I want to know what actually happened so I can make better use of that effect. This really is a more general open-source argument, especially pertinent to scientific code: can you explain how your algorithm works?

Another argument against ready-made software is that every tool implies some preferred ways of process and workflow. So you become accustomed to doing things in certain "professional" ways instead of thinking for yourself. It is much more interesting to build your own tools as you work; let the work shape the tools, not the other way. Your tools become part of your art, while there is this ongoing negotiation between the tech side and the art. You will probably get stuck in some of your own ways, but at least they will be something you came up with, instead of doing the same thing as all the other "professionals".

Something like Processing might give a good start for algorithmic art, but with such "user-friendly" systems there are always limitations that you'll run into sooner or later. My Python-gnuplot setup was easy enough for 12-16 year olds, and we went straight into real code and real commandline tools.

I don't think programming should be hard for its own sake. After all, I use Python for my demos, which I find much simpler and easier than the default Java used by Processing (though sensibly enough, it can also use Python).

On style and subject

I am interested in mathematics, and programming is my way of doing and understanding math. I try to find new ways of portraying "old" math, and keep the math simple enough to show through the art. While computers are all about computing, not all computer-generated art deserves to be called math art. There is math behind flashy, photorealistic effects, but one can choose to go math-first or flashy-first.

A key element in most math art is iteration: repeating a simple process over and over. The result will not be as simple, but it usually retains some innate harmony of the simple process. In music, harmony stems from simple ratios of frequencies; iterated function systems often exhibit the same ratios repeated on many levels, which I believe contributes to a sense of visual harmony. Conversely, flashy-first approaches often combine multiple different techniques, and the esthetics come more directly from the artist, rather than letting the math speak for itself.

My math-first philosophy is sometimes at crossroads with the desire to finish well-defined works of art. This is one reason why I prefer live visual demos, as they can be used together with music and other forms of performance for a more "artistic" whole, while staying unfinished themselves.

Running live programs also facilitates realtime control in response to other performers and audience reactions. But I also have more prosaic reasons to avoid fixed works. Fine detail and pointillist graininess is often ruined by video compression, so viewers get a second-rate version of what I've intended (this is especially bad with streaming video sites). Finally, there's good old-fashioned programming pride: I can do this in realtime, while limiting myself to last decade's GPU technology :-j

On political art

There is a lot I could say about political art in general, little of which would be endearing. But my math-art has a simple and somewhat unpolitical message: math is art, a creative human endeavour like nothing else.

More specifically, I am concerned about the divide between the two cultures, arts vs. sciences. It is hard to make informed decisions on your future when you are told to choose between the soft, cuddly, fuzzy and spiritual arts, or the soulless and tedious but lucrative world of math and science.

For schoolchildren and young students, image is everything. If you're a creative type and also good at math, it can be hard to choose a math-strong career when the everyone around you thinks math is just an endless drill with numbers after numbers. Of course, a lot of the "math" taught in schools is arithmetic number-crunching, so it's easy to get the wrong idea. But in order to do new math or science, one needs to combine a bit of that school-like rigour with a heap of creativity.

In fact, during my days as a math and science teacher, I was quite concerned about the image of scientific careers, and I aimed to keep things exciting. I tried to exemplify someone who can wear flashy clothes and have fun while being a real scientist. I was also wondering if I could focus on the flashy demonstrations and experiencements as a career, rather than spending my energy on all that basic teaching. In a sense, I'm now doing something like that with my math art.

[2020-09-22] For Finnish readers, I recommend this essay by Anna Tuori and Aleksis Salusjärvi on political art.

On giving credit

[2019-06-16] Algorithmic or mathematical art itself is thousands of years old. Arguably, some of the earliest of all artworks can be considered algorithmic, for instance Comb Ceramic pottery. So as I express my appreciation for pioneers such as these guys, I am referring to the modern, computerized wave. It is also where I find a lot of my pet peeves.

The computer-algorithmic pioneers had no ready-made software to begin with, and they were forced to code their own tools, should they want to produce any computer art at all. There is no question that their "art" also carried the meaning of "skill" in addition to "pretty pictures". They did all the work and they deserve all the respect they can get.

Today, it is getting harder to tell how much of the final work is due to the artists themselves, and how much is really done by an army of uncredited programmers behind the tech. Social media is full of people pushing buttons in ready-made apps and calling themselves artists. In an age of flashy superficies and sub-minute video clips, few people seem have the attention span to care any deeper, and I guess that's OK within the so-me bubble.

Unfortunately, professional artists are not immune either. I have seen prominent exhibitions with artists that took all the credit while admitting in passing that they hired some unnamed code monkeys to do all the work. Well, getting paid is better than nothing, but in my opinion, lack of credit is worse than working for free. The "artist" vs. "code monkey" discourse is not exactly helping bridge the aforementioned divide.

Of course, practically everyone uses some ready-made tools in some ways. There is a vast grey area between photo-fx apps and low-level programming. I am grateful for having Linux and other open-source tools in the foundations of my software stack, and I'm not interested in reinventing the wheel unless I'm doing an artwork about wheels. Along those lines, ask yourself

  1. Who/what makes the artistic decisions? You or the software you're using?
  2. Could you do you art without using some particular ready-made software?
The answers might help you tell whose art you are presenting as your own.

I guess one general problem comes from the clash of the two cultures. Academic credit is all about citing others and recognizing your place in the network of knowledge, while artistic pride is rooted in the idea of a lone genius. I believe both sides have something to learn from the other; the humble science-servant should fight for recognition in the face of comments such as "it's just math". (Corollary: if it's really "just math" then perhaps you don't need any of our code either.)

Also, the classic "it's not real art, you're just pushing buttons on a computer". Rather than dismissing the artistic value of the result, it is really about trivializing the art of computing; the result may or may not be art, but the button-pusher is hardly the one to take credit for all the work.

While the app disease is spreading, the real programming tools are also becoming more accessible all the time. I recommend learning Python, but any programming language is a good start.

Open source software

Starting with Linux in 1999, I use Free/Open source software almost exclusively (Nvidia Linux drivers being the main exception). I have also contributed to other projects and released my own, with the prominent examples on my Github account. That said, I have no plans to release my math-art code. It is an ongoing personal art project.

In open source, it is best to release projects that are

I certainly don't have well-defined clean code here. The remaining points mean unpaid work and time away from my art and personal life. On the other hand, I am open to serious offers with decent compensation (not necessarily money).

Still, I started my OpenGL framework from some GPL3 examples. So if I ever have a reason to release this code, it will be open source under the GPL3. In the meantime, please enjoy my math and tech notes, may you be inspired in your own art :)

Workshop code

In 2017 I taught a workshop of fractal art at a local school, for 12-16 year olds. The course material contains simplified Python scripts for my pointillist method, along with the gnuplot files and some instruction to get you started. Please note the above support considerations — if this works for you, that's great, but don't expect free support.

back to main page