Rhea Myers

Technical Problems

The perceived lack of psychological content, subjectivity, interiority, or affect is not a problem that concerns me in art computing. It is a deficiency of criticism, not the art under consideration. Software is ultimately made by human beings and its output is experienced by them. Visions of order are psychologically and ideologically interesting if you choose to look into them. Fractals, alife and evolutionary art all have this cognitive and social aesthetic value. Their un-Frankfurt-school-illustrating nature is a feature, not a bug, of their artistic worth.

Much modern art is, like art computing, produced at one remove. Brit Art was not produced by the artists who signed it for the most part but by the same East London foundry. Not only is the work manufactured there but the technical problems involved in realising the work are solved there by someone other than the artist. The same is true of Jeff Koons’s or Damien Hirst’s manufacturing teams.

This disconnect between the solving of technical problems and the experienced aesthetics of artworks is a problem that can and does affect some art computing. Historically progressive artworks consist in no small part of the solutions to the technical problems of their own construction. These are artistic, aesthetic, representational, material technical problems involved in the work of making the artwork. Their resolution can be seen in the finished work. The value of the artist is in solving them. How do you depict a riot, heaven, neoliberal economic hyperspace? Not with charcoal on the walls of your cave.

The bureaucratic, economic or unseen technological problems of making an artwork are not aesthetically interesting. They can be drawn in and animated by the artwork in order to criticise its environment, they can be used as indexes or signifiers, but talking about them is not a substitute for the artwork showing them. To add to rather than detract from the artwork, technical problems must be what making the artwork itself consists of and in; problems of representation or realisation rather than problems of preparation or administration. Their solution is an exercise of artistic skill and is part of the uniqueness and thereby the validity of the artwork.

Technological affordances are the opposite of non-artistic technical problems. If technology suddenly allows you to do something, making art that way does not solve technical problems encountered in artistic production. It simply illustrates the new technique. Technological affordances can be used to solve technical problems, but this is unlikely or at best trivial if it only involves the presets. The problems must come from demands made by and on the artwork, the solutions must come from the artist’s practice. Technology may be the medium or the subject of art, but it cannot be the cause.

The technical problems of creating a technological environment in order to support making art, whether in hardware or software, compare to studio clean-up and are not of interest if they cannot be seen as part of the finished work. The technological affordances of third-party software and hardware are not of interest if they are not used to solve artistic technical problems other than the ones they have been pre-packaged to solve. Demo culture detracts from art (I mean tech demos, not the “demo scene”).

Fractal, evolutionary and alife art might seem to fall foul of this. They are novel concepts implemented in code. But they take little code to produce and its results can be seen on the screen. They are the realisation of theories of order that touch on ideological concerns such as the social darwinism, reductionism and visual order of the 1970s and 1980s. I believe that this makes them of greater interest than simple negativist visual critiques of the same ideas, or at least that they are a useful bad conscience for any attempt to un-self-critically lionise those ideas.

Historically progressive, artistically and socially worthwhile art computing would have to exist somewhere between mere technological problem solving external to the finished artwork and mere technological affordances entirely determining the finished artwork. That is, somewhere between PhotoShop presets and heroically hacking endless code just to paint the screen blue.

This somewhere between is at the level of producing the least code required for the greatest effect in the experienced artwork. Given the current state of computer technology, with millions of lines of source code available online as Free Software and hundreds of sources of data and computation exposed online as web services, hacking on existing code (editing it, not cracking it) and producing enough new code ¯to solve technical problems in the production of the artwork but not enough that the production of code becomes the hidden part of an iceberg of which the experience of the artwork is just the tip is probably the current sweet spot for art computing.

Writing this, I realise that this is how we approached art computing at the Centre For Electronic Art at Middlesex University in the 1990s. Students were provided with code frameworks to build on and modify to make work, and with the skills to study and extend those frameworks as needed. I didn’t write this essay to work backwards to the CEA as an ideal model, but it was a very successful model.