I just have to say, since this is what greeted me on Rhizome this evening, that I personally have never been convinced of the benefits of the artist + engineer/programmer/scientist collaboration idea. I'm sure that something like '9 evenings' was a remarkable event way back when but I'm not convinced that it was a significant ART event. I'm going to try to explain what I think is wrong with such collaborations (not that they ARE wrong, just what I think goes wrong).
The main thing is the language barrier. I don't believe that it's possible for an artist and an engineer to talk the same language. Both of these areas have their own terms and vocabularies which makes the seemingly simple task of conveying ideas, difficult. Try going into a Macdonalds and ordering "a double cheeseburger with secret sauce". Possibly, they might deduce that you want a Big Mac, but I'll bet that in most cases, they won't have any idea what your asking for. I used to go into Starbucks and ask for a large coffee and I found it strange that sometimes I would get a rather large coffee and sometimes I would get a huge coffee. Then I discovered that I wasn't using the appropriate Starbuck-ese and was, from that point on, able to control the size I got by asking for either a "grande" or a "venti". But it could have caused the same kind of confusion the other way around. The coffee slinger could have asked me, "Do you mean a grande or a venti?" I, not know the difference between a grande and a venti, would have put my brain to work for a second and thought, "well, I can deduce that 'grande' is something big but I have no idea what 'venti' means." And then picked the grande thinking that was the bigger of the two and then ended up NOT getting what I had intended on getting.
I don't know, maybe in the case of artist + engineer/programmer/scientist collaboration, that's one of those 'magical' places where 'new' ideas emerge. You know, playing off the misunderstandings instead of trying to avoid or correct them but I see it as a fault.
This idea of something "magical" brings me to another point. There's something about art. Something that's so hard to define and so hard to express in words, which is of course why we express it artistically. One of the things that makes it so hard to define is that it's capable of affecting different people in very different ways. My wife sometimes gets surprised when I say that such and such is such a happy song because to her, it's a sad song. How do we explain, and maintain that element that makes it possible for one person to feel one thing and another to feel the opposite. When something does get lost in this mess of language barriers and miscommunication, what do you think is the first to go. It must be that which is hardest to express verbally. That indescribable, magical, artistic element.
Another issue is lack of understanding of the media (and this, of course, can go both ways). I firmly believe that the more the artist knows about and understands the media that he or she is working with, the better the chance of creating something significant. If the artist is, for instance, providing the conceptual basis for a piece and relying on a collaborator to translate it into a medium or media, then, in most cases, the artist is working with a medium or media that they are unfamiliar with or lack a clear understanding of it. It seems to me that some people within the art world always assume that when an artist is working with computers, they have to collaborate with a programmer. That it's just not in the realm of the arts to learn any computer programming (except perhaps max/msp because it's visual). People talk about the "steep learning curve". Well, I don't think that programming *as an artistic medium* has a steeper learning curve than any other medium. I think what people mean is that to learn programming *in the way that professional programmers use programming* there is a steep learning curve. That's probably true. But if we're programming a work of art, we don't have to worry about generally accepted coding principles. We don't have to worry about our programs using resources efficiently. We don't have to worry about our code being easily readable to others and we don't have to worry about our programs being extensible. We can be messy, sloppy, inefficient. It only has to do exactly what that particular work of art requires. Nothing more.
Somehow, I can't shake the feeling that this idea of the necessity of collaboration in the field of New Media is an obsolete remnant of earlier times when artists needed to collaborate with engineers/programmers/scientists *just to gain access to the equipment*. And because it was so hard to gain access to it, they never had the opportunity to learn or understand it fully in an artistic medium sort of way. Today, when I probably have more power and technology than all the devices used by artists throughout the 70's, right here in my little laptop, that collaboration isn't necessary anymore. Also, I can spend as much time as I want and/or need to understand this technology as my chosen medium.
Final word: I don't really think that art is benefiting that much from these types of collaboration. Perhaps they provide an incentive to artists in general to explore and better what the collaborators were initially trying to do. Maybe I wouldn't be trying to gain an understanding of these media if Rauschenberg and Kluver had never gotten together. I don't know but I don't recall seeing anything truly artistically compelling as the result of such collaboration.
If I read this through a couple of times I'd probably find a few things I'd want to edit, but I'm going to stop now and toss this out there.
–
Pall Thayer
[email protected]
http://www.this.is/pallit
regarding the On Colaboration reblog on the Rhiz front page
-
Type: discussion
Comments
The 'artist/engineer collaboration' is sort of like this:
Suppose one were to write a book. Well, not really *write* the book, just tell someone who *can* write the general sort of thing one wants.
Telling an engineer what one wants the new media piece to be is like telling a technical writer what one wants the book of poetry to be like.
So much happens in the actual process of writing. Whether it's writing poetry or writing the code of a new media piece. To think a good new media piece can be brought into existence by the above method is far fetched. Sometimes it works though! Not very often, however.
ja
http://vispo.com
> But if we're programming a
> work of art, we don't have to worry about generally accepted
> coding principles. We don't have to worry about our programs
> using resources efficiently. We don't have to worry about our
> code being easily readable to others and we don't have to worry
> about our programs being extensible. We can be messy, sloppy,
> inefficient. It only has to do exactly what that particular work
> of art requires. Nothing more.
Artists don't have to study programming for years, it's true.
However, if you try to create a large program, you will be bonked on the head repeatedly by your own work until you learn the value of the principles of encapsulation, extensibility, good documentation, etc. You simply won't be able to do it without this sort of knowledge. It will be mental torture. You will cry for your mama. Been there, done that! And the work will die with you, certainly, because other programmers will gasp and cross themselves upon gazing at the code. Even if you were taught these principles, their value only really emerges, is evident, when you find yourself with a big project.
Which is to say that the *scope* of what you can do without studying the principles and methodologies of programming is limited to the one-off or the two-off, to the one-liner or the two-liner.
ja
http://vispo.com
An interesting point of view, but I think it still presumes a bit too
much that the stereotypical divide between art and science/
engineering is unbridgeable. There are people who live in both
worlds (not that many, but some) – and I think there's more of an
opportunity for cross-fertilization than one might think. I like
your idea of artists learning how to program — but engineers can
also learn to make art.
Most collaborations of this kind don't amount to much, I agree, but
speaking as someone with a foot in both worlds and who has done a lot
of collaboration of this type — I think there's room for something
very interesting to happen in the mixing of the two spaces. The
mixing would have to happen at a deeper level than typically occurs
– it goes beyond just language, into the boundaries between
different ways of thinking, perceiving, feeling, and being. What
interests me isn't merely adding the two worlds or juxtaposing them,
but creating hybrid spaces in which both aspects of art and
engineering work together.
M
On Sep 12, 2006, at 10:32 PM, Pall Thayer wrote:
> I just have to say, since this is what greeted me on Rhizome this
> evening, that I personally have never been convinced of the
> benefits of the artist + engineer/programmer/scientist
> collaboration idea. I'm sure that something like '9 evenings' was a
> remarkable event way back when but I'm not convinced that it was a
> significant ART event. I'm going to try to explain what I think is
> wrong with such collaborations (not that they ARE wrong, just what
> I think goes wrong).
>
> The main thing is the language barrier. I don't believe that it's
> possible for an artist and an engineer to talk the same language.
> Both of these areas have their own terms and vocabularies which
> makes the seemingly simple task of conveying ideas, difficult. Try
> going into a Macdonalds and ordering "a double cheeseburger with
> secret sauce". Possibly, they might deduce that you want a Big Mac,
> but I'll bet that in most cases, they won't have any idea what your
> asking for. I used to go into Starbucks and ask for a large coffee
> and I found it strange that sometimes I would get a rather large
> coffee and sometimes I would get a huge coffee. Then I discovered
> that I wasn't using the appropriate Starbuck-ese and was, from that
> point on, able to control the size I got by asking for either a
> "grande" or a "venti". But it could have caused the same kind of
> confusion the other way around. The coffee slinger could have asked
> me, "Do you mean a grande or a venti?" I, not know the differe!
> nce between a grande and a venti, would have put my brain to work
> for a second and thought, "well, I can deduce that 'grande' is
> something big but I have no idea what 'venti' means." And then
> picked the grande thinking that was the bigger of the two and then
> ended up NOT getting what I had intended on getting.
>
> I don't know, maybe in the case of artist + engineer/programmer/
> scientist collaboration, that's one of those 'magical' places where
> 'new' ideas emerge. You know, playing off the misunderstandings
> instead of trying to avoid or correct them but I see it as a fault.
>
> This idea of something "magical" brings me to another point.
> There's something about art. Something that's so hard to define and
> so hard to express in words, which is of course why we express it
> artistically. One of the things that makes it so hard to define is
> that it's capable of affecting different people in very different
> ways. My wife sometimes gets surprised when I say that such and
> such is such a happy song because to her, it's a sad song. How do
> we explain, and maintain that element that makes it possible for
> one person to feel one thing and another to feel the opposite. When
> something does get lost in this mess of language barriers and
> miscommunication, what do you think is the first to go. It must be
> that which is hardest to express verbally. That indescribable,
> magical, artistic element.
>
> Another issue is lack of understanding of the media (and this, of
> course, can go both ways). I firmly believe that the more the
> artist knows about and understands the media that he or she is
> working with, the better the chance of creating something
> significant. If the artist is, for instance, providing the
> conceptual basis for a piece and relying on a collaborator to
> translate it into a medium or media, then, in most cases, the
> artist is working with a medium or media that they are unfamiliar
> with or lack a clear understanding of it. It seems to me that some
> people within the art world always assume that when an artist is
> working with computers, they have to collaborate with a programmer.
> That it's just not in the realm of the arts to learn any computer
> programming (except perhaps max/msp because it's visual). People
> talk about the "steep learning curve". Well, I don't think that
> programming *as an artistic medium* has a steeper learning curve
> than any other medium. I think !
> what people mean is that to learn programming *in the way that
> professional programmers use programming* there is a steep learning
> curve. That's probably true. But if we're programming a work of
> art, we don't have to worry about generally accepted coding
> principles. We don't have to worry about our programs using
> resources efficiently. We don't have to worry about our code being
> easily readable to others and we don't have to worry about our
> programs being extensible. We can be messy, sloppy, inefficient. It
> only has to do exactly what that particular work of art requires.
> Nothing more.
>
> Somehow, I can't shake the feeling that this idea of the necessity
> of collaboration in the field of New Media is an obsolete remnant
> of earlier times when artists needed to collaborate with engineers/
> programmers/scientists *just to gain access to the equipment*. And
> because it was so hard to gain access to it, they never had the
> opportunity to learn or understand it fully in an artistic medium
> sort of way. Today, when I probably have more power and technology
> than all the devices used by artists throughout the 70's, right
> here in my little laptop, that collaboration isn't necessary
> anymore. Also, I can spend as much time as I want and/or need to
> understand this technology as my chosen medium.
>
> Final word: I don't really think that art is benefiting that much
> from these types of collaboration. Perhaps they provide an
> incentive to artists in general to explore and better what the
> collaborators were initially trying to do. Maybe I wouldn't be
> trying to gain an understanding of these media if Rauschenberg and
> Kluver had never gotten together. I don't know but I don't recall
> seeing anything truly artistically compelling as the result of such
> collaboration.
>
> If I read this through a couple of times I'd probably find a few
> things I'd want to edit, but I'm going to stop now and toss this
> out there.
> –
> Pall Thayer
> [email protected]
> http://www.this.is/pallit
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/
> 29.php
>
>
Jim Andrews wrote:
>> But if we're programming a
>> work of art, we don't have to worry about generally accepted
>> coding principles. We don't have to worry about our programs
>> using resources efficiently. We don't have to worry about our
>> code being easily readable to others and we don't have to worry
>> about our programs being extensible. We can be messy, sloppy,
>> inefficient. It only has to do exactly what that particular work
>> of art requires. Nothing more.
>
> Artists don't have to study programming for years, it's true.
They should. ;-) I studied programming in C and Java intensively on the
Compiting In Art & Design course at MDX in the mid-nineties, and have
continued learning since.
> However, if you try to create a large program, you will be bonked on the head repeatedly by your own work until you learn the value of the principles of encapsulation, extensibility, good documentation, etc. You simply won't be able to do it without this sort of knowledge. It will be mental torture. You will cry for your mama. Been there, done that! And the work will die with you, certainly, because other programmers will gasp and cross themselves upon gazing at the code. Even if you were taught these principles, their value only really emerges, is evident, when you find yourself with a big project.
This is very true. It's like not knowing composition, colour mixing,
fat-over-lean or paint drying times when painting.
> Which is to say that the *scope* of what you can do without studying the principles and methodologies of programming is limited to the one-off or the two-off, to the one-liner or the two-liner.
There are useful one or two line programs, but to really engage with the
medium takes a depth of knowledge, as with any medium.
- Rob.
I personally suck at programming although have an understanding of the
basics. Never really liked doing it, thought it was boring.
Dreamweaver was a godsend to me.
In my collaborations I felt they always came off best when someone was a
specialist in this or that but still was creative at the same time.
The PAM group that I am in is a perfect example. We all make up for what the
other lacks and we have a number of cross over points that make it easy for
us to trouble shoot and brainstorm. None of us could have built the project
without all four of us together.
On 9/13/06 3:27 AM, "Rob Myers" <[email protected]> wrote:
> Jim Andrews wrote:
>>> But if we're programming a
>>> work of art, we don't have to worry about generally accepted
>>> coding principles. We don't have to worry about our programs
>>> using resources efficiently. We don't have to worry about our
>>> code being easily readable to others and we don't have to worry
>>> about our programs being extensible. We can be messy, sloppy,
>>> inefficient. It only has to do exactly what that particular work
>>> of art requires. Nothing more.
>>
>> Artists don't have to study programming for years, it's true.
>
> They should. ;-) I studied programming in C and Java intensively on the
> Compiting In Art & Design course at MDX in the mid-nineties, and have
> continued learning since.
>
>> However, if you try to create a large program, you will be bonked on the head
>> repeatedly by your own work until you learn the value of the principles of
>> encapsulation, extensibility, good documentation, etc. You simply won't be
>> able to do it without this sort of knowledge. It will be mental torture. You
>> will cry for your mama. Been there, done that! And the work will die with
>> you, certainly, because other programmers will gasp and cross themselves upon
>> gazing at the code. Even if you were taught these principles, their value
>> only really emerges, is evident, when you find yourself with a big project.
>
> This is very true. It's like not knowing composition, colour mixing,
> fat-over-lean or paint drying times when painting.
>
>> Which is to say that the *scope* of what you can do without studying the
>> principles and methodologies of programming is limited to the one-off or the
>> two-off, to the one-liner or the two-liner.
>
> There are useful one or two line programs, but to really engage with the
> medium takes a depth of knowledge, as with any medium.
>
> - Rob.
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/29.php
>
>
>They should. ;-) I studied programming in C and Java intensively on the
Compiting In Art & Design course at MDX in the mid-nineties, and have
continued learning since.
For those following the so-called 'Charlie' thread, it might be of
interest that so did I, though a little earlier, before Java, and using
greenscreen command line dumb terminals connected to a Vax VMS and then
a Silicon Graphics Iris
Mind you unlike Rob I don't still use or learn such things 'cos I am now
just a theorist
Charlie Gere
Reader in New Media Research
Director of Research
Institute for Cultural Research
Lancaster University Lancaster LA1 4YL UK
Tel: +44 (0) 1524 594446
E-mail: [email protected]
http://www.lancs.ac.uk/fss/cultres/staff/gere.php
Rob Myers wrote:
>
> This is very true. It's like not knowing composition, colour mixing,
> fat-over-lean or paint drying times when painting.
True, but when we learn to draw or paint, we don't begin with these issues. They're introduced as we go along.
>
> > Which is to say that the *scope* of what you can do without studying
> the principles and methodologies of programming is limited to the
> one-off or the two-off, to the one-liner or the two-liner.
>
> There are useful one or two line programs, but to really engage with
> the
> medium takes a depth of knowledge, as with any medium.
I appear to contradict myself on this issue since I do say that the artist should know as much about the medium as possible and then go on to say that the artist doesn't need to know all there is about programming. But I think one of the problems with the more traditional approach to programming (and I'm just basing this on books and tutorials that I've seen) is, for instance, the idea that you have to have a fully formed idea about how the program is going to function before you begin to write it. I don't agree. I think it's entirely possible to build up a framework around an idea that you intend to explore further once the program gets to a stage where you can run something. But that's where it tends to get messy. Change a little here, something over there, this breaks, fix it by changing this thing here, etc. I think, from an artistic standpoint, that it's also important to maintain a certain degree of flexibility during the process of creating the program. Of course, the more the artist uses programming, the more they will come to know and appreciate certain standards. But I think it's perfectly all right to let it happen over time and even through personal discovery.
>
> - Rob.
I don't recall anyone saying that you are "just" a theorist and see no reason to continue misinterpreting something for the sake of maintaining some imagined animosity from my end.
Pall
wrote:
>
>
>
> >They should. ;-) I studied programming in C and Java intensively on
> the
> Compiting In Art & Design course at MDX in the mid-nineties, and have
> continued learning since.
>
>
> For those following the so-called 'Charlie' thread, it might be of
> interest that so did I, though a little earlier, before Java, and
> using
> greenscreen command line dumb terminals connected to a Vax VMS and
> then
> a Silicon Graphics Iris
>
> Mind you unlike Rob I don't still use or learn such things 'cos I am
> now
> just a theorist
>
> Charlie Gere
> Reader in New Media Research
> Director of Research
> Institute for Cultural Research
> Lancaster University Lancaster LA1 4YL UK
> Tel: +44 (0) 1524 594446
> E-mail: [email protected]
> http://www.lancs.ac.uk/fss/cultres/staff/gere.php
>
At 8:27 AM +0100 9/13/06, Rob Myers wrote:
>This is very true. It's like not knowing composition, colour mixing,
>fat-over-lean or paint drying times when painting.
I don't think these are apt comparisons to what an engineer knows or does.
It's not necessary to know the chemical composition of paint in order to
make paintings. It's not necessary to know the science of color. It's not
necessary to know how a stepper motor works in order to use one in a piece
IF you have access to productized tech.
The medium is not the medium (i.e. the materials)
Painters can buy paint now - they don't have to make it. Artists can buy
Arduino and use add on boards to drive stepper motors without knowing all
the tech behind them. These are forms of collaboration between engineers
and artists - extremely formalized - but collaborations none the less. I
think tech is a huge sinkhole for artists. Yes, there are creative
opportunities and ideas that arise from DIY but there is also a huge amount
of wasted time.
I think raising the question of 'language differences' between artists and
scientists (+ engineers, etc) misses the point of collaboration: that
interpreting and finding a common language is part of the process. It
assumes willing participants on both sides - which was what EAT was about.
That's wholly different than me hiring a contract programmer or going to a
machine shop and waving my hands around as I describe my project.
–Roy
–
—————————————————————–
Studio Blog: http://www.roypardi.com/
Exhibit Announcements: http://www.roypardi.com/announce.htm
Gandhi - "Be the change you want to see in the world"
Calm down - just a joke
Charlie Gere
Reader in New Media Research
Director of Research
Institute for Cultural Research
Lancaster University Lancaster LA1 4YL UK
Tel: +44 (0) 1524 594446
E-mail: [email protected]
http://www.lancs.ac.uk/fss/cultres/staff/gere.php
—–Original Message—–
From: [email protected] [mailto:[email protected]] On Behalf
Of Pall Thayer
Sent: 13 September 2006 14:18
To: [email protected]
Subject: RHIZOME_RAW: Re: Re: regarding the On Colaboration reblog on
the Rhiz front page
I don't recall anyone saying that you are "just" a theorist and see no
reason to continue misinterpreting something for the sake of maintaining
some imagined animosity from my end.
Pall
wrote:
>
>
>
> >They should. ;-) I studied programming in C and Java intensively on
> the
> Compiting In Art & Design course at MDX in the mid-nineties, and have
> continued learning since.
>
>
> For those following the so-called 'Charlie' thread, it might be of
> interest that so did I, though a little earlier, before Java, and
> using greenscreen command line dumb terminals connected to a Vax VMS
> and then a Silicon Graphics Iris
>
> Mind you unlike Rob I don't still use or learn such things 'cos I am
> now just a theorist
>
> Charlie Gere
> Reader in New Media Research
> Director of Research
> Institute for Cultural Research
> Lancaster University Lancaster LA1 4YL UK
> Tel: +44 (0) 1524 594446
> E-mail: [email protected]
> http://www.lancs.ac.uk/fss/cultres/staff/gere.php
>
+
-> post: [email protected]
-> questions: [email protected]
-> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
-> give: http://rhizome.org/support
+
Subscribers to Rhizome are subject to the terms set out in the
Membership Agreement available online at http://rhizome.org/info/29.php
I don't see all that much difference between artists and scientists/engineers/slash/slash. Scientists have to 'prove' their findings, artists don't. Other than that, its about the same. So it seems to me that inspiration and creativity can happen at either end in a collaboration, no matter the differing language or materials of each. I don't collab much myself (yet?) because I'm split brained and am crazy enough to try and do both jobs at once.
-stevie read
> I appear to contradict myself on this issue since I do say that
> the artist should know as much about the medium as possible and
> then go on to say that the artist doesn't need to know all there
> is about programming. But I think one of the problems with the
> more traditional approach to programming (and I'm just basing
> this on books and tutorials that I've seen) is, for instance, the
> idea that you have to have a fully formed idea about how the
> program is going to function before you begin to write it. I
> don't agree. I think it's entirely possible to build up a
> framework around an idea that you intend to explore further once
> the program gets to a stage where you can run something. But
> that's where it tends to get messy. Change a little here,
> something over there, this breaks, fix it by changing this thing
> here, etc. I think, from an artistic standpoint, that it's also
> important to maintain a certain degree of flexibility during the
> process of creating the program. Of course, the!
> more the artist uses programming, the more they will come to
> know and appreciate certain standards. But I think it's perfectly
> all right to let it happen over time and even through personal discovery.
The most boring thing to write is something that's thought-out before it's written. Lifeless. So much depends upon the actual process of writing. So much happens there that can't be anticipated and changes where the program's going.
The principles and methodologies of programming are mainly designed to create flexibility so that one *can* change things as one proceeds with the programming relatively easily. It's harder to change spagetti code than nicely modularised code. On the other hand, it's more time consuming to write nicely modularised code than spagetti code. So inevitably programs are a tradeoff between sound programming principles and the need to get on with it. You bet you won't need to modularize x but know you might with y.
I'm currently doing some work on Arteroids 3.0. Figuring out what I was doing in 2.0 is sometimes hard. Sometimes easy. Sometimes I did it right. Sometimes I was in a hurry. Some things were early in development and I'll pay for it now. Other things, thank gawd, are easier.
ja
http://vispo.com
Steve OR Steven Read wrote:
> I don't see all that much difference between artists and scientists/engineers/slash/slash.
"Painting is a science, and should be pursued as an enquiry into the
laws of nature. Why, then, should not landscape painting be considered
as a branch of natural philosophy, of which pictures are but the
experiments?" - John Constable.
"Progress in science comes when experiments contradict theory." - Feynman
- Rob.
i remember reading, erm, john carmack–or someone like that–say something like 'the art of programming is in picking the features that both extend the program and offer least resistance to further development.' a narrow conception of the art of programming. but an interesting observation about how programs develop over time.
1.0 is tabula rasa. 2.0 has lots of room. with 3.0 the clay is starting to solidify.
by now, with director, say, which has been around since 1987, they can't change many things, but simply add new things with little (or merely standard) relation to what already exists.
a poet once told me that a story should follow from its premises.
the fundamental architecture contains the end.
our main strengths and weaknesses are often intertwined.
ja
http://vispo.com
Quoting Pall Thayer <[email protected]>:
> But I think one of the problems with the more traditional approach to
> programming (and I'm just basing this on books and tutorials that
> I've seen) is, for instance, the idea that you have to have a fully
> formed idea about how the program is going to function before you
> begin to write it. I don't agree. I think it's entirely possible to
> build up a framework around an idea that you intend to explore
> further once the program gets to a stage where you can run something.
> But that's where it tends to get messy. Change a little here,
> something over there, this breaks, fix it by changing this thing
> here, etc. I think, from an artistic standpoint, that it's also
> important to maintain a certain degree of flexibility during the
> process of creating the program. Of course, the!
> more the artist uses programming, the more they will come to know
> and appreciate certain standards. But I think it's perfectly all
> right to let it happen over time and even through personal discovery.
Oh definitely. One problem for art computing is that people tend to use
Java or
C++. These are statically typed, compiled languages that you do need to design
programs for using all that boring software design methodology before
you start
coding otherwise you will quickly get lost. They are also brittle when you
change things, and unforgiving when they fail. Even Processing inherits
some of
these problems, being based on Java.
A more hackerish way of coding is called "exploratory programming". This is
where you start writing code, see where it goes, then extend the program to
follow your ideas. It's much easier to do this style of programming in a
dynamically typed, interpreted or interactive language like the scripting
languages or the Lisp family. It's like using oil paint rather than tempera.
;-)
If you've ever seen Livecoding those guys tend to use Perl or another
scripting
language in an interactive interpreter. That gets you close to the code in
realtime.
So for a more fliud way of pursuing ideas in code I do recommend dynamic
languages and exploratory programming.
- Rob.
> I think raising the question of 'language differences' between artists
> and
> scientists (+ engineers, etc) misses the point of collaboration: that
> interpreting and finding a common language is part of the process. It
> assumes willing participants on both sides - which was what EAT was
> about.
> That's wholly different than me hiring a contract programmer or going
> to a
> machine shop and waving my hands around as I describe my project.
>
> –Roy
> –
> —————————————————————–
> Studio Blog: http://www.roypardi.com/
> Exhibit Announcements: http://www.roypardi.com/announce.htm
> Gandhi - "Be the change you want to see in the world"
this is a true point, but its equally true for two collaborating artists.
may be it is useful to distinguish between different kinds of collaboration.
there is one type of collaboration, which I would rather call service-collaboration. It is this type where e.g. the artists needs scientific/technical advice or the scientists wants to "beautify some visualizations". But there is also a
type where probably both parties should just be called "artists"…regardless from their background.
Pall et al
Isn't there another thread, which is the collaboration with science/ soft engineering for funding reasons?
Sci-art funding has been one of the main commisioning sources ion the U.K. for years and has resulted in a lot of technology as spectacle work here, kind of "end of the pier" work, which is IMO the very stuff Pall is referring to.
The collaboration with other fields of cultural production nearly always seems to produce work which is lacking in some way for me, maybe thats my taste buds talking or maybe its to do with something around intention and if collaboration with "not art" inevitably means the work is completed or is successful in terms which art cannot reach…
wrote:
> Calm down - just a joke
>
>
> Charlie Gere
> Reader in New Media Research
> Director of Research
> Institute for Cultural Research
> Lancaster University Lancaster LA1 4YL UK
> Tel: +44 (0) 1524 594446
> E-mail: [email protected]
> http://www.lancs.ac.uk/fss/cultres/staff/gere.php
>
>
> —–Original Message—–
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Pall Thayer
> Sent: 13 September 2006 14:18
> To: [email protected]
> Subject: RHIZOME_RAW: Re: Re: regarding the On Colaboration reblog on
> the Rhiz front page
>
> I don't recall anyone saying that you are "just" a theorist and see no
> reason to continue misinterpreting something for the sake of
> maintaining
> some imagined animosity from my end.
>
> Pall
>
> wrote:
>
> >
> >
> >
> > >They should. ;-) I studied programming in C and Java intensively on
> > the
> > Compiting In Art & Design course at MDX in the mid-nineties, and
> have
> > continued learning since.
> >
> >
> > For those following the so-called 'Charlie' thread, it might be of
> > interest that so did I, though a little earlier, before Java, and
> > using greenscreen command line dumb terminals connected to a Vax
> VMS
> > and then a Silicon Graphics Iris
> >
> > Mind you unlike Rob I don't still use or learn such things 'cos I
> am
> > now just a theorist
> >
> > Charlie Gere
> > Reader in New Media Research
> > Director of Research
> > Institute for Cultural Research
> > Lancaster University Lancaster LA1 4YL UK
> > Tel: +44 (0) 1524 594446
> > E-mail: [email protected]
> > http://www.lancs.ac.uk/fss/cultres/staff/gere.php
> >
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe:
> http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at
> http://rhizome.org/info/29.php
>
Patrick
hi,
interesting, not sure how you mean this:
>> maybe its to do with something around intention and if
>> collaboration with "not art" inevitably means the work is
>> completed or is successful in terms which art cannot reach…
, that the projects resulting from the UK sci-art funding , tend
towards a semiotics e. g.
'in terms of'
>> in terms which art cannot reach…
?
would enjoy further elaboration
c
On Sep 15, 2006, at 6:33 AM, Patrick Simons wrote:
> Pall et al
>
> Isn't there another thread, which is the collaboration with
> science/ soft engineering for funding reasons?
> Sci-art funding has been one of the main commisioning sources ion
> the U.K. for years and has resulted in a lot of technology as
> spectacle work here, kind of "end of the pier" work, which is IMO
> the very stuff Pall is referring to.
>
> The collaboration with other fields of cultural production nearly
> always seems to produce work which is lacking in some way for me,
> maybe thats my taste buds talking or maybe its to do with something
> around intention and if collaboration with "not art" inevitably
> means the work is completed or is successful in terms which art
> cannot reach…
>
>
>
>
>
>
> wrote:
>
>> Calm down - just a joke
>>
>>
>> Charlie Gere
>> Reader in New Media Research
>> Director of Research
>> Institute for Cultural Research
>> Lancaster University Lancaster LA1 4YL UK
>> Tel: +44 (0) 1524 594446
>> E-mail: [email protected]
>> http://www.lancs.ac.uk/fss/cultres/staff/gere.php
>>
>>
>> —–Original Message—–
>> From: [email protected] [mailto:[email protected]] On
>> Behalf
>> Of Pall Thayer
>> Sent: 13 September 2006 14:18
>> To: [email protected]
>> Subject: RHIZOME_RAW: Re: Re: regarding the On Colaboration reblog on
>> the Rhiz front page
>>
>> I don't recall anyone saying that you are "just" a theorist and
>> see no
>> reason to continue misinterpreting something for the sake of
>> maintaining
>> some imagined animosity from my end.
>>
>> Pall
>>
>> wrote:
>>
>>>
>>>
>>>
>>>> They should. ;-) I studied programming in C and Java intensively on
>>> the
>>> Compiting In Art & Design course at MDX in the mid-nineties, and
>> have
>>> continued learning since.
>>>
>>>
>>> For those following the so-called 'Charlie' thread, it might be of
>>> interest that so did I, though a little earlier, before Java, and
>>> using greenscreen command line dumb terminals connected to a Vax
>> VMS
>>> and then a Silicon Graphics Iris
>>>
>>> Mind you unlike Rob I don't still use or learn such things 'cos I
>> am
>>> now just a theorist
>>>
>>> Charlie Gere
>>> Reader in New Media Research
>>> Director of Research
>>> Institute for Cultural Research
>>> Lancaster University Lancaster LA1 4YL UK
>>> Tel: +44 (0) 1524 594446
>>> E-mail: [email protected]
>>> http://www.lancs.ac.uk/fss/cultres/staff/gere.php
>>>
>> +
>> -> post: [email protected]
>> -> questions: [email protected]
>> -> subscribe/unsubscribe:
>> http://rhizome.org/preferences/subscribe.rhiz
>> -> give: http://rhizome.org/support
>> +
>> Subscribers to Rhizome are subject to the terms set out in the
>> Membership Agreement available online at
>> http://rhizome.org/info/29.php
>>
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/
> 29.php
Christina McPhee wrote:
> interesting, not sure how you mean this:
> , that the projects resulting from the UK sci-art funding , tend
> towards a semiotics e. g.
>
> 'in terms of'
"UK sci-art funding bodies perceive (or evaluate) the work's success in
non-art terms."
This is the problem with instrumentalsation of art by the state, and is
self-defeating.
- Rob.
On 16 Sep 2006, at 16:03, Rob Myers wrote:
> instrumentalsation
Or instrumentalisation, if one proofreads one's emails properly
before sending them. ;-)
- Rob.
Hi Christina, Rob…….
Sorry for the delay in responding, been away from my collaborative workstation for a bit.
In terms of my garbled and wandering post, the distinction I was attempting to draw was between work (art) produced within a broadly art like orbit (oh dear) AND work (colllaborations with evil mad scientists) which reduces the artlike ness of the work (the sort of stuff which fills stands at trade fairs) to spectacle.
I am conscious that this may seem dismissive or pompous or elitist (in sense that Bourdieu relates the concept of "taste") but the difficulty with trying to discuss the edge of art and say interactive design when looking at technology, artists and programmers and so on, seems to me to be increasingly about the nature and form that the collaboration between them takes.
An example to illustrate my vague badly focussed point might be something like when French Cubists were enlisted by the military to paint cubist patterning on camouflage netting during the Great War, to disguise tank and gun positions on the front line. The artists were employed (commissioned) and asked to do what they do, paint distended and fragmented forms onto the canvas (netting). They were left to produce forms and patterns of their own design and the only restriction placed on them was the colour pallette of camouflage paints.
Is this an example of a healthy collaboration between art and not art or is it a commission with guide lines, AND an underlying intention for the work, being that it successfully FUNCTIONS in not art terms.
Patrick
best wishes
Patrick
glorious ninth
Christina McPhee wrote:
> Patrick
>
> hi,
>
> interesting, not sure how you mean this:
>
> >> maybe its to do with something around intention and if
> >> collaboration with "not art" inevitably means the work is
> >> completed or is successful in terms which art cannot reach…
>
>
> , that the projects resulting from the UK sci-art funding , tend
> towards a semiotics e. g.
>
> 'in terms of'
>
> >> in terms which art cannot reach…
>
>
> ?
>
> would enjoy further elaboration
>
>
> c
>
>
>
>
> On Sep 15, 2006, at 6:33 AM, Patrick Simons wrote:
>
> > Pall et al
> >
> > Isn't there another thread, which is the collaboration with
> > science/ soft engineering for funding reasons?
> > Sci-art funding has been one of the main commisioning sources ion
> > the U.K. for years and has resulted in a lot of technology as
> > spectacle work here, kind of "end of the pier" work, which is IMO
> > the very stuff Pall is referring to.
> >
> > The collaboration with other fields of cultural production nearly
> > always seems to produce work which is lacking in some way for me,
> > maybe thats my taste buds talking or maybe its to do with something
>
> > around intention and if collaboration with "not art" inevitably
> > means the work is completed or is successful in terms which art
> > cannot reach…
> >
> >
> >
> >
> >
> >
> > wrote:
> >
> >> Calm down - just a joke
> >>
> >>
> >> Charlie Gere
> >> Reader in New Media Research
> >> Director of Research
> >> Institute for Cultural Research
> >> Lancaster University Lancaster LA1 4YL UK
> >> Tel: +44 (0) 1524 594446
> >> E-mail: [email protected]
> >> http://www.lancs.ac.uk/fss/cultres/staff/gere.php
> >>
> >>
> >> —–Original Message—–
> >> From: [email protected] [mailto:[email protected]] On
> >> Behalf
> >> Of Pall Thayer
> >> Sent: 13 September 2006 14:18
> >> To: [email protected]
> >> Subject: RHIZOME_RAW: Re: Re: regarding the On Colaboration reblog
> on
> >> the Rhiz front page
> >>
> >> I don't recall anyone saying that you are "just" a theorist and
> >> see no
> >> reason to continue misinterpreting something for the sake of
> >> maintaining
> >> some imagined animosity from my end.
> >>
> >> Pall
> >>
> >> wrote:
> >>
> >>>
> >>>
> >>>
> >>>> They should. ;-) I studied programming in C and Java intensively
> on
> >>> the
> >>> Compiting In Art & Design course at MDX in the mid-nineties, and
> >> have
> >>> continued learning since.
> >>>
> >>>
> >>> For those following the so-called 'Charlie' thread, it might be of
> >>> interest that so did I, though a little earlier, before Java, and
> >>> using greenscreen command line dumb terminals connected to a Vax
> >> VMS
> >>> and then a Silicon Graphics Iris
> >>>
> >>> Mind you unlike Rob I don't still use or learn such things 'cos I
> >> am
> >>> now just a theorist
> >>>
> >>> Charlie Gere
> >>> Reader in New Media Research
> >>> Director of Research
> >>> Institute for Cultural Research
> >>> Lancaster University Lancaster LA1 4YL UK
> >>> Tel: +44 (0) 1524 594446
> >>> E-mail: [email protected]
> >>> http://www.lancs.ac.uk/fss/cultres/staff/gere.php
> >>>
> >> +
> >> -> post: [email protected]
> >> -> questions: [email protected]
> >> -> subscribe/unsubscribe:
> >> http://rhizome.org/preferences/subscribe.rhiz
> >> -> give: http://rhizome.org/support
> >> +
> >> Subscribers to Rhizome are subject to the terms set out in the
> >> Membership Agreement available online at
> >> http://rhizome.org/info/29.php
> >>
> > +
> > -> post: [email protected]
> > -> questions: [email protected]
> > -> subscribe/unsubscribe: http://rhizome.org/preferences/
> > subscribe.rhiz
> > -> give: http://rhizome.org/support
> > +
> > Subscribers to Rhizome are subject to the terms set out in the
> > Membership Agreement available online at http://rhizome.org/info/
> > 29.php
>