biosounda r ttext
CubeLife history and sources
While searching for a structure and a medium, I received timely exposure to some of the historical sources of digital art practice, in the form of two seminars hosted by Loughborough University's Gallery of the Future. One was by Harold Cohen, who - using the programming language Lisp (good for Artificial Intelligence) as a medium - is an example of how computer science and art can interact (AARON creates paintings, which is another issue altogether). In the other seminar Paul Brown described how he adapted the ABC of artificial life theory to create evolving images. At the time, it was also encouraging to me personally that both - like many other digital artists - prefer Apple machines, with which I have also had a long relationship. After this exposure, I surveyed the landscape by trawling the web to find out what was being shown online (and incidentally discovered a review in Wired News of the 1997 New York show that was based on artist-modified vintage 512K Macs, as a comment on their digital art pedigree).
I was by then beginning to combine the several component areas of my life - creativity, mathematics and computer skills. I was familiar with the fundamentals of programming logic, having cut my teeth on Apple's venerable (and now discontinued) rapid application development environment (RAD) Hypercard, the structure of which also prepared me for object-oriented languages (and the original concepts behind hyperlinks). I was also familiar with the basics of artificial life, certain mathematical patterns, and the images that can be formed by experimenting with these. I chose Java because it was then an emerging language, solves the cross-platform problem in one go, and works on the web. I also wanted to explore a 'proper' language by collaborating with another programmer, since scripting or RADs (like Director/Lingo, and x-talk languages like HyperTalk) then had limits, although the Hypercard programme (left) I wrote to research and test magic square patterns remains a useful research tool (despite the fact that I haven't yet successfully ported it to a web app or Runtime Revolution). But why programme? Because during the process of creating, I invariably want to do non-standard things with computers, or follow ideas unlikely to be available within the limits of commercial software.
Work generated by commercial software can often look assembled, not created. For instance, image manipulation tools like Photoshop contain a lot of baggage that can be visible in the finished work, just as - in the early days of digital typography - randomly distorted type appeared everywhere simply because it was possible. The clever stuff in the code of a standard application can warp the path of the creative process. Working as an artist directly in a programming language offers more control over the computer as a medium and I can create my own tools, with no clutter, to use the way I want. Anything I can't create with my own partial skills, I develop in collaboration.
The interpretation of number pattern through cultural symbolism provides a rich resource, offering connections between apparently disparate material - the connection between Leibniz's binary numbers and the Chinese I Ching is a case in point. As another example, Albrecht Dürer's 'Melancholia II' (right) contains the first known representation of a magic square in European art, and Dürer's straddling of the mathematical and artistic worlds offers an early example for contemporary art-science crossovers. His famous engraving also hints at the lost Renaissance view of melancholy as a portal to inspiration, explored fully in Frances Yates' book The occult philosophy in the Elizabethan age. The body of thinking behind the cultural use of mathematical forms is a long-standing interest which I am exploring as part of my art practice.
As well as the artistic and cultural sources informing cubeLife, I am also interested in the mathematics. I've become mildly serious (for a non-mathematician, anyway) about number theory and combinatorics, two branches of pure mathematics that can be used as tools to examine magic squares and cubes. During a separate residency at Loughborough University's computer science department, I began working with programmer Simon Nee to construct a tool in C++ to examine magic square structures (the work became the casualty of busy schedules and reorganisation, but the thinking is still there), initiated communication with some of the web's magic square specialists, and made some minor explorations, some of which remain to be written up (I need a friendly mathematician to help with proofs, and some free time!).
Working as an artist in an HCI department meant I could pursue ideas in computer science that explore unconventional interfaces to computer-driven art. The idea behind the heartbeat input to cubeLife is to facilitate a warm and instant biological connection to an otherwise cool mathematically-based structure. I like the idea of bridging the schism between digital space and meatspace in a direct physical way, without resorting to a standard interface - everyone alive has a heartbeat so, as far as audience input goes, cubeLife aims to be the most widely accessible work possible.
Because each object in the virtual 3D space has a finite life granted by the data provided by each participant's heartbeat, there exist possibilities for variations in the mutations each object can undertake [Note: as of version 2, some of these have been added as options by collaborator Greg Turner]:
CubeLife is therefore a long-term project, likely to develop in ways I can't yet foresee, according to collaboration, ongoing research and emerging technology.
- first: by using heartbeat speed to personalise each created object (the current routine uses only the number of pulses until the monitor clip is removed, although pulse speed is visible as the object grows on-screen);
- second: by gathering other biological data to drive inter-dependant routines in the code. Furthering this latter idea is a developing interest in a kind of elementary complexity theory, where routines interact and are co-dependent so that the results become more unpredictable or even artificial intelligence-like, yet remain within defined parameters.
David Everitt, May-July '99. Revised '03 (CSS); May '06 (edit, new links).
t o p