CODeDOC
Digital Art is not a purely visual medium but always consist of a mostly invisible back end--source code or scripting languages--and a front end, the results created by "computer language." These results can manifest themselves in visuals or a more abstract process that allows for a form of communication in the broadest sense. Source code is a set of instructions formulated in a language that can be understood by the computer.

In traditional art forms, the “signature” and “voice” of an artist manifests itself in aesthetics of visuals and execution. Every medium may have its specific language but in digital art, this language has a quite literal rather than figurative manifestation. The visual results of an artwork are derived from the language of code. Languages are defined by grammar and complex rules and at the same time leave space for individual forms of creative expression. Our identity and the roles we play are expressed in our use of language. One might assume that the aesthetics of artists who write their own source code manifest themselves both in the code itself and its visual results. How much of a personal signature is found in an artist's source code?

"CODeDOC" takes a “reverse” look at artists' projects by focusing on and comparing the back end of the code. A dozen artists are invited to code a specific assignment in a language of their choice and to exchange the code with each other for comments. The emphasis is placed on process and data while the results are made visible only after the code. The project explores both the artist's creative expression on the level of source code and the linguistic universe of code.



Languages: Java, C/++, VB; Perl, Lingo, xml
[html and FlashScript have been excluded for pragamatic reasons]


Assignment and Requirements:
  • The code should move and connect three points in space. [This could obviously interpreted in a visual or more abstract way].

  • The code should not exceed 8 KB. 8 KB refers to your "main." The emphasis and focus is on code written by the artist. Obviously it's almost impossible to *not* call any libraries and subroutines but if possible, you should avoid relying on them too much (if they haven't been written by yourself); meaning, the idea is not that you write one line that calls powerful subroutines and libraries. However, if you can't resist bending the rules, please write a short line explaining what you did (so it becomes a bit more intelligible for anyone who isn't a programmer).

  • The code must be compilable / interpretable; it should run in a browser window or be accessible as downloadable executable.

  • The "object" is the code itself not what it produces. "Visual beauty" does not have to be the main focus.

  • By the deadline, you should deliver your code as a text file + the applet / exe etc.

  • The "assignment" will be collected and made available to everyone on a website. You are invited to comment on each others' projects. You do *not* have to comment on every participant's code; you can decide to stick to the artists' code that has been written in the language of your choice (or comment on whatever interests you).

  • The “exhibition” of the project at the artport website will present each artist's code as well as the comments submitted by the other artists. The visuals / process created by the respective code can be launched from each artist's section.


    (Tentative) Objectives:
    Obviously, this is a more experimental and process-oriented project, and it can't be predicted what exactly the outcome will be. You shouldn't just strive to illustrate the potential outcome I'm outlining below.

    The project could (but does not have to) show

    *the differences between the respective coding / scripting languages

    *the differences and/or similarities between artists' approaches -- be it in how they interpret the assignment or write their code

    *the various relationships between code and its results