Programmers approach image making as a compositional form in which the computer “performs” image generation. Although this process has a visual outcome, it has similarities to musical composition and requires that the image be understood as a sequence of instructions. As Jean-Pierre Hébert says:
To be precise […] the artist-programmer must analyze how to describe exactly – or “compose” or “program” – the making of the image, ie its content making which is narrowly linked with the physical image production process anticipated […] then s/he must program the computer to execute the whole image making process (content definition and image production).[1]
Hébert points out that the final production process is of key importance to the artist, as this dictates what type of file they produce and how they go about making the image. For artists (like Hébert) who aim to make a physical object, this problem is especially relevant. Programming is thus a foundation for creativity, the start of a process that results in an image or physical artwork. Through programming, an artist may arrive at a deep comprehension of the underlying system, and a surer knowledge of its visual consequences. Of course, the starting point is very important: as Hébert puts it: “First of all the Artist-programmer must have an initial longing, a vision, a motif, a composition in mind, and a plan to bring them into existence.”[2]
As the artist and programmer team Colette and Charles Bangert explained, in the process of artificially dissecting the drawing process to make it amenable to computer production they discovered much about the nature of drawing itself. Colette, the artist, pointed to the counter-intuitive attempt to think about the act of drawing in order for a program to be written; each drawing element was treated as an independent object in the program: “This is artificial. Yet, this artificiality is precisely one aspect of the use of a mathematical attitude “.[3]
Katherine Nash and Richard H Williams outlined three fundamental approaches to making Computer Art in 1970. At this point, of course, GUI interaction was not an option, so each approach was based on programming:
1. [The artist] can set aside a portion of his time to learn a computer language and then write a program for the making of a work of art.
2. He can collaborate with a computer engineer in the making of a work of art.
3. He can work with a computer that already has within its memory bank an art language upon which he can draw to make a work of art.[4]
Nash and Williams wrote a specific art programming language, “ART 1”, to assist with this third point, which was covered at length by Leonardo. ART I, which resulted from an artist and engineer collaborating, was “meant as a bridge between the artist’s world and the world of technology.” It was written to be as approachable as possible for an artist learning programming, and was intended to run on a variety of computers – quite a feat at the time, considering the number of mutually incompatible operating systems around.
[ART I] is written to use the simplest and least expensive equipment. It is meant as a bridge between the artist’s world and the world of technology.[5]
In part, ART 1 was also intended to increase the artist’s competence and knowledge of programming; it contained graphics-specific commands that were less obscure than those of more mainstream languages.
This vision of an artistic programming language exemplifies the advantages – and limitations – of the computer artist’s interface before the advent of the GUI. To create images, the artist had to comprehend at least some of the processes within the computer and how they could be deployed. However, a specific artistic programming language was already a step towards commercial graphics packages. Most of the artist-programmers mentioned in this thesis have mastered standard programming languages and gone on to create their own software.
Artists who develop their own graphics packages may produce a more distinctive style than those who use ‘off-the-shelf’ software, because software plays an important role in delineating the artist’s workspace. If certain parameters and tools are already in place when the artist begins a new work, then the software has already exercised a strong influence on that piece. Much depends on the range of tools available and the structuring of menu options: 3D graphics programs will obviously contain a markedly different selection of tools, with very different purposes, compared with 2D programs.
The interaction between artist and program is constrained at certain points by the limitations of the software, and also by its focus on a particular type of graphical technique. Because the computer is not necessarily a passive partner, its responses (and foibles) add another layer of interaction. This is where the deeper knowledge gained by developing their own program grants programmers a better conceptual picture of the computer’s capabilities and the framework of the software.
An artist-programmer shapes computer code to suit his purpose: thus an artistic programmer creates the framework within which the art is generated. When the artist works at the level of the code, they are effectively designing their own medium and defining the structures that populate it. The computational problem for the artist is the production of their work, in a form that is amenable to computer processing. They have to write algorithms controlling the computer.
A definition of the term ‘algorithm’ states it is: “any well-defined computational procedure that takes some value, or set of values, as input and produces some value, or set of values, as output. An algorithm is thus a sequence of computational steps that transform the input into the output.” The algorithm is also a tool for solving a “well-specified computational problem”. The “problem” includes the specifically artistic methods deployed by the computer artist to construct their images. “The algorithm describes a specific computational procedure for achieving that input/output relationship.” [6]
This conception of art in algorithmic terms helps these artists structure and develop their art in ways that are inaccessible to artists who use the computer as if the screen were a canvas. As Frederick Hammersley noted from his first experiences of programming a computer for images in 1968:
[…] I, myself, am not actually making the drawing with my hands. My involvement and participation is very different from my feeling when painting, which may be a shortcoming. It might, on the other hand, be an asset to me; it may furnish me upon my return to either drawing or painting with new insights and added understanding. [7]
Hébert indicates a “fundamental feed back loop or evolution rule” at work here: the idea that programming can furnish new insights even though it is not a hands-on artform.[8] Although the artist’s involvement might seem to be at one remove from the actual generation of the image, they take on the role of director and composer. Charles Csuri considers this indirect creation to be as satisfactory as making an image with physical tools. Although he has gone from using physical tools to typing in commands, he contends that writing in a computer language enables him to “organize and structure the artistic content and meaning.” He claims that spontaneity in this medium is derived from understanding and applying these sequences of code:
When I set mathematical values, my mind is sensing choices as patterns of color and light. I see the relationships between objects as transformations involving position, rotation and scale.[9]
Thus the act of making art is sublimated into the concept of directing processes to make this art by proxy. This is not without precedent in the visual arts: I have already mentioned Renaissance artists’ workshops, with assistants executing large portions of paintings under the master’s direction; theatrical, dance and cinematic productions work in analogous ways.
Artist-programmers effectively impose their own limitations on their chosen medium, and the resulting software is a much closer reflection of their approach to art (and their programming abilities) than commercial software ever could be. Indeed, Harold Cohen lauds the value of programming as a discipline:
Real programming requires a close analysis and clear definition of the task to be performed, then an ability to design a program and devise the required algorithms. This is an intellectual discipline of the first order that has a potential in education beyond the technicalities of programming computers.[10]
Harold Cohen’s programming is the very essence of his AARON system, which gains its apparent artistic independence through Cohen’s skill at describing processes and habits of thought as rules that direct the system. [11] Thus he has made the computer an essential collaborator in the creation of art, deftly transferring his software from platform to platform until it has finally achieved a sort of independence, in the form of a screensaver that can run on PCs and Macs. Cohen contends that he has “cloned” the artist rather than the artwork, in spite of the constraints upon its image output. Crucially, Cohen’s system allows for the extension of AARON’s “knowledge”, and its range of artistic responses. However, Hébert does not see an artist in this constrained system: “it’s more a mummy than a clone”, in the sense that the mummified Egyptian preserves the outer appearances but is not alive.
David Gelernter sees programming as a framework for ideas. By working with this framework, one encounters constraints but in overcoming these, Gelernter feels that art may be produced:
Software architecture is no medium for untrammelled whimsy. It imposes ironclad discipline on the designer: The point is to solve a hard problem efficiently, not to make art. But good designers in any medium make art despite themselves […] because art, after all, requires discipline. You can’t push if nothing is pushing back.[12]
The intricacies of programming languages inform the overall method of creating an image and the artist has to build around these obstacles to realise their vision. The resultant image will be the product of this process of probing and exploiting the strengths and weaknesses of the chosen language. Cohen, for instance, deploys specialised Artificial Intelligence languages to achieve AARON’s processes. This suggests the action of an artistic collaborator “conversing” with the artist through its resistance and results, limited though that collaboration might be. Again, here is Hébert’s creative cycle, with the computer acting as a sounding board for the artist.
Larry Cuba considers that this affinity with software develops over time as a form of “long-term interaction”, the natural result of building one’s own program. The programmer tunes their software to their own way of working, or, like Cohen, enables the computer to develop ways of generating images independently. This reflects Manfred Mohr’s understanding of the feedback process between artist and computer as a “a learning process on the side of the human being, resulting in a clearer image of the creator’s thinking and intentions.”[13] As Ehrenzweig noted, the very nature of a medium causes an artist to modify their initial ideas:
A new idea will inevitably be modified through its impact on the resisting medium and conversely impose entirely new uses on the medium. […] Something like a true conversation takes place between the artist and his own work.[14]
Cuba’s conversation with his software has gone on for over twenty years. By contrast, the leading commercial graphics packages have developed over fifteen years or less, including many major changes in their interfaces and operation. The advantage for Cuba is not only that his program has grown and developed alongside his artistic growth, but also that his knowledge and control over his chosen medium has substantially increased
Roman Verostko also thinks that in algorithmic art, an individual style is the consequence of the artist’s customisation of the software. The very choices made in the process of image generation come to determine the overall style of the completed work. [15]
[1] Correspondence with JPH, Nov 2002
[2] Correspondence with JPH
[3] Colette S. Bangert & Charles J. Bangert, interviewed by Ruth Leavitt in Artist and Computer, 1976 p20
[4] “Computer program for Artists: Art 1” Katherine Nash and Richard H. Williams Leonardo 1970 or Computers and Mathematics?
[5] “Computer program for Artists: Art 1” Katherine Nash and Richard H. Williams Leonardo 1970 or Computers and Mathematics?
[6] Cormen, Leiserson & Rivest Introduction to Algorithms (1994, MIT) p1
[7] “My First Experience with Computer Drawings”, Frederick Hammersley (LEONARDO, Vol.2, pp407-409, 1969); from Visual Art, Mathematics and Computers: Selections from the Journal LEONARDO ed. Frank J. Malina (Oxford 1979), pp284-286.
[8] Correspondence with JPH, Nov 2002.
[9] Csuri, Charles “Tactile-Kinesthesis”
[10] Leavitt, ibid, p8
[11] Harold Cohen “Off the shelf”, The Visual Computer (1986) 2 : 191 – 194c Springer – Verlag 1986
[12] Gelernter, David Mirror Worlds (Oxford, 1991), p114
[13] Manfred Mohr, interviewed in Artist and Computer, 1976, pp92-96
[14] Ehrenzweig, Anton The Hidden Order of Art (London 19xx), p57
[15] “Algorithms and the Artist” Roman Verostko, paper for a panel on Algorithms and the Artist at the Fourth International Symposium on Electronic Art, Helsinki, September 1994.
