damian3
Since 2007

Discussions (6) Opportunities (0) Events (0) Jobs (0)
DISCUSSION

Regarding Conceptual and Aesthetic Implications of Code in Computer-based Art


Well, if the code is seen as a series of instructions to the machine then I wonder why is it removed from being Art as some of the respondents insist.

i spoke to some friends who were at Pixelache, and actually saw the lecture this discussion is based on, about this. they're not programmers. they passed on this point, though:

because it's not directly experienced as part of the artwork (unless that action is taken deliberately by the artist). it can aid in the interpretation, if you understand code, sure, but not in any way that is any more or less special than seeing conceptual drawings, notebooks, and studies can aid in the understanding of a painting or a sculpture.

i don't think anyone is denying this last point. Pall seems to arguing for something stronger than this, though, almost a necessity for code to always be shown alongside the executing software. but this would be like trying to claim that a painter's notebooks relating to this painting should always be shown alongside their paintings.

DISCUSSION

Regarding Conceptual and Aesthetic Implications of Code in Computer-based Art


In the case of computer-programmed art, we could add another step to completing the circuit, that being the computer. If you're viewing a work of mine, then what you see on your screen as the software runs isn't being created by me. It's being created by your computer based on the code from me. In that sense, the code is the artwork. It's the only element that I am the sole creator of. Everything else, the way the computer displays it, the way that the viewer views it, is an interpretation of that artwork.

i don't think the nature of the computer is special enough to warrant this extra step in the circuit. it's not an 'interpreter' in the sense that we as humans are interpreters. this is an important distinction between software art and works by the likes of Sol Lewitt: in Sol Lewitt's case a good chunk of the interest in exposing the code comes from the involvement of people (human interpreters) in the execution of the code. we want to read the code so that we can understand what it felt like to be one of the co-creators of the artwork, or so that we can understand what the artist wanted to put the co-creators through; our interest in code here is i think tied very firmly to the fact that the interpreters are human.

the computer i think needs to be viewed the same way we view the kiln in the case of the ceramic sculptor, or the printing press in the case of the printmaker, or the video player in the case of the video artist. it's just a tool to turn something raw into something, err, 'cooked'. It is this 'cooked' object that can then be interpreted as an 'artwork': raw clay into ceramic sculpture, negative relief into positive print, magnetic field variations on tape into images on a television, and in the case of software art, code (text file) into executed program (software/'runningness'/whatever you want to call it).

-
or from another angle: imagine i am Michelangelo. i give a set of instructions to my 50 assistants, then i go home to ponder the infinite, popping in and out again make some changes to the instructions as necessary. my 50 assistants then paint the ceiling of the Sistine Chapel. in which case, the ceiling of the Sistine Chapel is being created by my assistants based on the set of instructions from me. In that sense, the set of instructions is the artwork. It's the only element that I am the sole creator of. Everything else, the way the assistants paint it, the way that the viewer views it, is an interpretation of that artwork.

DISCUSSION

Regarding Conceptual and Aesthetic Implications of Code in Computer-based Art


Pall Thayer wrote:
> You're
> entitled to your opinions but if I don't think that they match the
> context of my argument, then I don't see anything wrong with pointing
> that out.

the thing is i think they *do* match the context of your argument. this is what i mean by not engaging with my point of view. i don't care whether you agree with me or not, i just felt like you were dismissing many of the points that i was raising because they 'didn't match the context of your argument'. which is just plain rude. you asked for feedback on your paper, i've given you feedback. there were a lot of other things i could've been doing (learning Supercollider, working on some code for one of my own pieces, going for a walk under the moonlight, ...) but i chose to give you feedback. then to have it dismissed in this way, it's just plain rude. i've been arguing on the intertubes for far too long to take it personally, but it makes me much less likely to want to engage with you in the future.

i admire you for sticking to your point of view so strongly, but i maintain that i think you're confusing process, medium, and product (the 'art object' for want of a better term). either that, or you're trying to take something that applies to just a subset of code-based art and apply it to all art that uses code.

from the first paragraph of your paper:

"... Yet it
 IS the work. The work couldn't exist without it. It controls every single aspect of the “experience.” Furthermore, It is the medium that the creator of the work molds and fashions into the “experience.”"

there are three terms you're using here: code, "experience", and medium.
- on the one hand, you claim the code controls every single aspect of the "experience", ie the code controls the experience but is not the same as the experience.
- on the other hand you claim that the code is the medium that becomes the "experience" through a processing of molding and fashioning, ie the code is transformed into the experience through the act of programming, ie once the artwork is finished the code just is the experience.

but you can't have it both ways. code cannot both control every aspect of the experience, and be the experience itself, except in specific instances where that is the intention of the artist.

and i don't think you can get out of this by substituting the word 'software' for 'code': code as language can be experienced in the same way that writing or poetry can be experienced; but code under execution, what i mean by 'software', cannot be directly experienced except through some interface (screen, speakers, lights, motors, etc), and even then, it can only be experienced as its effects or controls on that interface, and not directly.

Philip raised a very good point, which pins down something where i'm coming from, that i don't think you've addressed:

"... one could pin paper printouts of a computer program on the wall and claim that it is a work of art. And it's not the same at all as claiming that in a digitally driven installation (for example) the art isn't the images and sounds and interactions delivered, but rather the art is actually the unseen code. "

at best, the argument you're raising refers to a specific subset of code-based artwork, and this is the subset where the code is written to be seen as well as to be experienced (e.g. 'code poetry', poetry that is also an executable program). but i don't think it applies to the kind of coding that someone will do for example for an entirely screen-based work, ie the kind of coding that makes up the vast majority of computer-based art. and if this is your point, then fine; just make it more clear exactly what you mean by "Computer-based Art".

lastly, and i don't expect anyone to agree with me on this, i think that if you need to see the code to understand what's going on - if i can't tell that there's 'love' involved without looking at the code, "if($image->{tag} eq 'love'){ produce_image(); }" - then the artwork has failed.

--
damian stewart | +351 967 797 263 | damian@frey.co.nz
frey | live art with machines | http://www.frey.co.nz

DISCUSSION

Regarding Conceptual and Aesthetic Implications of Code in Computer-based Art


ok. to be honest, i don't feel like you're willing engage with my point of view on this, and i'm not going to try and convince you to. sorry.

image

DISCUSSION

Regarding Conceptual and Aesthetic Implications of Code in Computer-based Art


Pall Thayer wrote:
> Hi Damian, thanks for the comments. I won't ignore because these are
> ideas I'm actively working on promoting and that I feel quite strongly
> about. I've met with quite a bit of animosity in discussing the ideas
> with others and I think it's primarily based on a misunderstanding of my
> intentions which is why I welcome any and all comments and discussion.

i don't know if i've misunderstood your intentions, but i do think you're confusing the medium and/or the process and/or the resulting art object.

> First of all, I'm not by any means claiming that coded artwork can't be
> understood or appreciated without regarding the code. I am suggesting
> that there's another level of understanding to be found within the code.

understanding of what?

i don't believe that you can better understand a program's /runningness/ (what it feels like to engage with the program) by examining its code. quite the opposite. i write my own software to make music, and one of the most interesting things about doing this is that often my own software reveals to me things that i didn't even know were there to be found. and after these new possibilities have presented themselves, there's no way i can point to any part of the code and say, this bit happens here. it's the whole system i'm interacting with, not particular parts.

may i suggest some reading:
http://mitpress.mit.edu/book-home.tcl?isbn=0262521121

> The code provides a very clear window into the
> artist's conceptual and aesthetic intentions.

no it doesn't. it provides a very clear window into their technical / engineering skills and abilities. like i said above, the aesthetic outcomes don't have a 1-1 relationship with the code. if i don't even know what new aesthetic/creative/phenomenological avenues my code is going to open up when i write it, how can anyone else expect to understand my intentions by reading it?

> Also, if we think about
> preservation, revealing the code provides for a means of preservation
> that would allow galleries and museums to "re-interpret" the work on
> future hardware.

if you were an artist working on an iron sculpture would you leave a list of instructions around to allow galleries and museums to 're-interpret' your sculpture using future metals? i don't think such 're-interpretation' is really possible without making new artwork. if you run the same code on different (future) hardware, i expect you'll end up with a different artwork. visual-based code written for a Commodore 64 plugged into a colour TV won't /feel/ the same when you run it on a desktop PC plugged into a plasma monitor, and so it will be a different artwork.

> Regarding "the medium" I have a question for you. Why are welding and
> painting media and not coding? If runningness (I like that term!) is the
> medium of coded art then how can welding be the medium of an iron
> sculpture? To me, runningness refers to what a piece does whereas
> welding refers to how something is created. I see a contradiction there.

my point was the opposite, actually. the process of welding is to an iron sculpture, as the act of painting is to the final painting you hang on the wall, as the act of coding is to the resultant software art. iron is the medium in the first, painting is the medium in the second, software/'runningness' is the medium in the third.

> The statement you refer to is not intended to ignore the earlier history
> of coded art. It simply serves as a convenient means of pointing to a
> distinct event, that most people in this field are familiar with, where
> code in art was specifically discussed and analyzed. However, I think it
> should have been the start of something rather than the start and
> finish, which is what seems to have happened.

perhaps there was nothing to discuss?

i just don't think the code is interesting from anything other than an engineering perspective; and there's nothing intrinsically special about software engineering that makes it so fundamentally different from mechanical engineering or any other kind of engineering used for artistic purposes.

--
damian stewart | +351 967 797 263 | damian@frey.co.nz
frey | live art with machines | http://www.frey.co.nz