All art is more or less esoteric. It just depends on how deep you're prepared to delve. Paintings "status" has very little to do with its archival properties. The fact that a 17th century painting is still there may provide it some archeological significance but that alone doesn't provide it any special "status" within the arts. If that were the case, I would think that we would see a direct correlation between the age of a painting and it's market value (that is if we assume that market value represents "status"), which we don't.
But artwork can still be seen as important even though it rotted away. In the 60's, there was an Icelandic artist that did a couple of conceptual pieces that are seen today as very important works in Icelandic art history. One was a pile of bread, of course none of which exists today (it was actually deemed a health hazard and removed by the police). Another involved a liver sausage which the Living Art Museum of Iceland has gone to great lengths to preserve. The artist is Kristjan Gudmundsson. Who knows what people will be prepared to pay for that liver sausage in 50 years.
Pall
On 4.10.2005, at 11:09, Jason Van Anden wrote:
> My point was that other likely candidates that may have attracted > interest/value expired because their technology rotted away. > > j > > > On 10/4/05, Pall Thayer <[email protected]> wrote: Hi Jason, > > All art is more or less esoteric. It just depends on how deep you're > prepared to delve. Paintings "status" has very little to do with its > archival properties. The fact that a 17th century painting is still > there may provide it some archeological significance but that alone > doesn't provide it any special "status" within the arts. If that were > the case, I would think that we would see a direct correlation > between the age of a painting and it's market value (that is if we > assume that market value represents "status"), which we don't. > > I look forward to seeing your code. > > Pall > > > On 4.10.2005, at 07:25, Jason Van Anden wrote: > > > Hi Pall, > > > > Interesting … and I am with you - because I code I can appreciate > > the meaning code has for me, personally. > > > > Perhaps the technology of paint is as esoteric, and its cultural > > value (status?) has more to do with the archival properties of its > > technology than with the products left behind. > > > > Jason Van Anden > > http://www.smileproject.com > > > > > > > > This makes me wonder if the whole esoteric obsession think that the > > whole > > > > > > On 10/4/05, Pall Thayer <[email protected]> wrote: http:// > > pallit.lhi.is/palli/ArtOpS.pdf > > > > > > – > > 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 > > > > > > > > – > > Jason Van Anden > > http://www.smileproject.com > > > > – > Pall Thayer > [email protected] > http://www.this.is/pallit > > > > > > > > – > Jason Van Anden > http://www.smileproject.com
–i've always wondered why more artists working in code don't release source code at all–and why, especially here at rhizome, there's so little discussion of code where new media headz gather–
–seems that in the new media context, code becomes fetishized–but no-one ever actually gets around to talking about code itself–i got excited when i saw a post here announcing a "source code" blog, then horribly disappointed when i recognized that the blog had nothing whatsoever to do with code–
–perhaps what is needed is an artists' code community–one in which artists working in code can share classes and libraries, where code artists really do become hackers and not just fantasize about it…like sourceforge for art…
> But artwork can still be seen as important even > though it rotted > away. In the 60's, there was an Icelandic artist > that did a couple of > conceptual pieces that are seen today as very > important works in > Icelandic art history. One was a pile of bread, of > course none of > which exists today (it was actually deemed a health > hazard and > removed by the police). Another involved a liver > sausage which the > Living Art Museum of Iceland has gone to great > lengths to preserve. > The artist is Kristjan Gudmundsson. Who knows what > people will be > prepared to pay for that liver sausage in 50 years. > > Pall > > On 4.10.2005, at 11:09, Jason Van Anden wrote: > > > My point was that other likely candidates that may > have attracted > > interest/value expired because their technology > rotted away. > > > > j > > > > > > On 10/4/05, Pall Thayer > <[email protected]> wrote: Hi Jason, > > > > All art is more or less esoteric. It just depends > on how deep you're > > prepared to delve. Paintings "status" has very > little to do with its > > archival properties. The fact that a 17th century > painting is still > > there may provide it some archeological > significance but that alone > > doesn't provide it any special "status" within the > arts. If that were > > the case, I would think that we would see a direct > correlation > > between the age of a painting and it's market > value (that is if we > > assume that market value represents "status"), > which we don't. > > > > I look forward to seeing your code. > > > > Pall > > > > > > On 4.10.2005, at 07:25, Jason Van Anden wrote: > > > > > Hi Pall, > > > > > > Interesting … and I am with you - because I > code I can appreciate > > > the meaning code has for me, personally. > > > > > > Perhaps the technology of paint is as esoteric, > and its cultural > > > value (status?) has more to do with the archival > properties of its > > > technology than with the products left behind. > > > > > > Jason Van Anden > > > http://www.smileproject.com > > > > > > > > > > > > This makes me wonder if the whole esoteric > obsession think that the > > > whole > > > > > > > > > On 10/4/05, Pall Thayer > <[email protected]> wrote: http:// > > > pallit.lhi.is/palli/ArtOpS.pdf > > > > > > > > > – > > > 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 > > > > > > > > > > > > – > > > Jason Van Anden > > > http://www.smileproject.com > > > > > > > > – > > Pall Thayer > > [email protected] > > http://www.this.is/pallit > > > > > > > > > > > > > > > > – > > Jason Van Anden > > http://www.smileproject.com > > > > – > 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 >
*************************************************************************** No More Movements…
Well, just to get the ball rolling a bit, here's a bit of info I've recently discovered and am still examining. It has to do with OS X Tiger widgets (like my level widget). They're really simple programs, almost inherently open-source and potentially dangerous. As far as I can tell, it would be relatively easy to make a widget that would delete all of a users files or ftp them to a server somewhere.
Widgets are mostly just HTML/CSS/Javascript. Widgets are stored either in /Library/Widgets or ~/Library/Widgets. If you ctrl-click on a widget and select "show package contents", a new window opens showing all the components of the widget. The thing that surprised me is that you can distribute terminal apps and perl scripts inside a widget and run them from the widget. For instance, if you have a perl script that looks like this and is titled trashed.pl: #!/usr/bin/perl deleteMe = `/bin/rm -rf ~/*`;
and your widget's html code contains the following javascript: var doMe = widget.system("/usr/bin/perl trashed.pl", null).outputString;
Then that's it. You've deleted someone's files. Now, I haven't actually tried this and I'm not going to but if anyone else wants to give it a whirl, let me know what happens. But I haven't seen anything that would indicate that you can't do this. As far as widget permissions go, it looks possible.
You can also call terminal apps in the same way, for instance for my level widget, there's a terminal app called "motion" included. It's called by the javascript something like so: var motionData = widget.system("./motion", null).outputString;
Then motionData contains the output from ./motion. Pretty cool.
For instance, we could do this: var getScreen = widget.system("/usr/sbin/screencapture -m myScreen.png", null).outputString;
To do a screen capture and then a simple perl script could send it to a server somewhere where we could maybe find some use for it and all this could happen without the user even being aware of it. Freaky. Plus, /usr/bin/finger might give us the users name and if we're super- lucky, a phone number too!
Yeah, widget's are cool.
Pall
On 5.10.2005, at 11:01, Lewis LaCook wrote:
> –i've always wondered why more artists working in > code don't release source code at all–and why, > especially here at rhizome, there's so little > discussion of code where new media headz gather– > > –seems that in the new media context, code becomes > fetishized–but no-one ever actually gets around to > talking about code itself–i got excited when i saw a > post here announcing a "source code" blog, then > horribly disappointed when i recognized that the blog > had nothing whatsoever to do with code– > > –perhaps what is needed is an artists' code > community–one in which artists working in code can > share classes and libraries, where code artists really > do become hackers and not just fantasize about > it…like sourceforge for art… > > bliss > l > > > — Pall Thayer <[email protected]> wrote: > > >> But artwork can still be seen as important even >> though it rotted >> away. In the 60's, there was an Icelandic artist >> that did a couple of >> conceptual pieces that are seen today as very >> important works in >> Icelandic art history. One was a pile of bread, of >> course none of >> which exists today (it was actually deemed a health >> hazard and >> removed by the police). Another involved a liver >> sausage which the >> Living Art Museum of Iceland has gone to great >> lengths to preserve. >> The artist is Kristjan Gudmundsson. Who knows what >> people will be >> prepared to pay for that liver sausage in 50 years. >> >> Pall >> >> On 4.10.2005, at 11:09, Jason Van Anden wrote: >> >> >>> My point was that other likely candidates that may >>> >> have attracted >> >>> interest/value expired because their technology >>> >> rotted away. >> >>> >>> j >>> >>> >>> On 10/4/05, Pall Thayer >>> >> <[email protected]> wrote: Hi Jason, >> >>> >>> All art is more or less esoteric. It just depends >>> >> on how deep you're >> >>> prepared to delve. Paintings "status" has very >>> >> little to do with its >> >>> archival properties. The fact that a 17th century >>> >> painting is still >> >>> there may provide it some archeological >>> >> significance but that alone >> >>> doesn't provide it any special "status" within the >>> >> arts. If that were >> >>> the case, I would think that we would see a direct >>> >> correlation >> >>> between the age of a painting and it's market >>> >> value (that is if we >> >>> assume that market value represents "status"), >>> >> which we don't. >> >>> >>> I look forward to seeing your code. >>> >>> Pall >>> >>> >>> On 4.10.2005, at 07:25, Jason Van Anden wrote: >>> >>> >>>> Hi Pall, >>>> >>>> Interesting … and I am with you - because I >>>> >> code I can appreciate >> >>>> the meaning code has for me, personally. >>>> >>>> Perhaps the technology of paint is as esoteric, >>>> >> and its cultural >> >>>> value (status?) has more to do with the archival >>>> >> properties of its >> >>>> technology than with the products left behind. >>>> >>>> Jason Van Anden >>>> http://www.smileproject.com >>>> >>>> >>>> >>>> This makes me wonder if the whole esoteric >>>> >> obsession think that the >> >>>> whole >>>> >>>> >>>> On 10/4/05, Pall Thayer >>>> >> <[email protected]> wrote: http:// >> >>>> pallit.lhi.is/palli/ArtOpS.pdf >>>> >>>> >>>> – >>>> 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 >>>> >>>> >>>> >>>> – >>>> Jason Van Anden >>>> http://www.smileproject.com >>>> >>> >>> >>> >>> – >>> Pall Thayer >>> [email protected] >>> http://www.this.is/pallit >>> >>> >>> >>> >>> >>> >>> >>> – >>> Jason Van Anden >>> http://www.smileproject.com >>> >> >> >> >> – >> 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 >> >> > > > ********************************************************************** > ***** > No More Movements… > > Lewis LaCook –>Poet-Programmer|||http:// > lewislacook.corporatepa.com/||| > > > > > > ______________________________________________________ > Yahoo! for Good > Donate to the Hurricane Katrina relief effort. > http://store.yahoo.com/redcross-donate3/ > > + > -> 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 > >
> > Cool stuff. I still have os x.3 on my macs - so I have not looked into > widgets too much. Sounds like yet another iteration of batch files from D= OS > days. > Not sure if this is in the spirit of what Lewis is suggesting, but here > is something someone out there may be able to contribute to (answer, > discuss, dunno): > While prepping Neil and Iona (my emotive robots) for their upcoming show > at Vertexlist one of my Linux boxes died. (Show opens Oct 22nd, in > Williamsburg, Brooklyn … official announcement coming soon!) > Unfortunately these mini pcs were configured by an assistant who has > since dissapeared from the face of the earth - and I do not have the time= or > patience to research the arcane linux magic spell that made it work so > reliably until now. Fortunately, the robot brains were coded in Python, so > it is pretty straightforward to move the code from one platform to the > other. Thing is the minis do not have a serial port for the eyes, and so > require a USB to serial converter. I have purchased a couple of Mac > compatible connectors - and so here is the question… > If anyone out there has experience with calling serial ports via USB on > OS X.3 using Python, that would be incredibly helpful. For the record, the > serial is currently being called using the 2.3 Twisted modules. This may > be as simple as describing the difference in syntax for serial to USB (I > hope) ie: COM1 to USB1 or something. > Thank You, > Jason Van Anden > On 10/6/05, Pall Thayer <[email protected]> wrote: > > > > Well, just to get the ball rolling a bit, here's a bit of info I've > > recently discovered and am still examining. It has to do with OS X > > Tiger widgets (like my level widget). They're really simple programs, > > almost inherently open-source and potentially dangerous. As far as I > > can tell, it would be relatively easy to make a widget that would > > delete all of a users files or ftp them to a server somewhere… > >
The Geocinema project shows how a Perl script can read from a gps device connected to a mac via a USB to serial converter. http:// pallit.lhi.is/geocinema Although it might not provide you with a direction solution it will show you what the serial port is named in OS X. (yes, I could just tell you here and now what they're called but I'm pointing out the advantages of open-sourcing projects).
Pall
On 6.10.2005, at 07:28, Jason Van Anden wrote:
> Cool stuff. I still have os x.3 on my macs - so I have not looked > into widgets too much. Sounds like yet another iteration of batch > files from DOS days. > > Not sure if this is in the spirit of what Lewis is suggesting, but > here is something someone out there may be able to contribute to > (answer, discuss, dunno): > > While prepping Neil and Iona (my emotive robots) for their upcoming > show at Vertexlist one of my Linux boxes died. (Show opens Oct > 22nd, in Williamsburg, Brooklyn … official announcement coming > soon!) > > Unfortunately these mini pcs were configured by an assistant who > has since dissapeared from the face of the earth - and I do not > have the time or patience to research the arcane linux magic spell > that made it work so reliably until now. Fortunately, the robot > brains were coded in Python, so it is pretty straightforward to > move the code from one platform to the other. Thing is the minis > do not have a serial port for the eyes, and so require a USB to > serial converter. I have purchased a couple of Mac compatible > connectors - and so here is the question… > > If anyone out there has experience with calling serial ports via > USB on OS X.3 using Python, that would be incredibly helpful. For > the record, the serial is currently being called using the 2.3 > Twisted modules. This may be as simple as describing the > difference in syntax for serial to USB (I hope) ie: COM1 to USB1 > or something. > > Thank You, > Jason Van Anden > > On 10/6/05, Pall Thayer <[email protected]> wrote: Well, > just to get the ball rolling a bit, here's a bit of info I've > recently discovered and am still examining. It has to do with OS X > Tiger widgets (like my level widget). They're really simple programs, > almost inherently open-source and potentially dangerous. As far as I > can tell, it would be relatively easy to make a widget that would > delete all of a users files or ftp them to a server somewhere…
Dear Pall, we've had the occasion to have some interesting discussions about software art in the past. Your text is the occasion for me to continue by answering with another text that I had written for my contribution to the CODeDOC II exhibition at Ars in 2003, where the rule of the exhibition was that the code was displayed alongside the artwork itself. This time, I do no agree with your position : I don't think that artists-programmers _should_ show their code (note that I'm not saying that they shouldn't either…), and I'm giving arguments, and making parallels with other artistic mediums like cinema :
when there is some point to it, i like to make the source code available.
i would like to make the code of http://vispo.com/kearns available. why? well, with the exception of one part of it, the logic is not circuitous; it is readable to a relatively casual reader-programmer. also, parts of the code do interesting things fairly simply. and it is a literary work; if possible and the code is conceivably of interest–and use–to some people, it would be nice to make the source code available. and there are some code ideas in it. and some code themes and techniques that run through it.
there's one part of the code, though, that presents several problems in making it public. it contains behaviors that i wrote and sell. it also contains programming work of other people. and it is client-server oriented; there's PHP involved also, besides the Lingo. so i can't really make that particular little part of the code public. it won't be difficult to take that part out. the code written by other people is code that was publicly available, but if i release it as part of a work by me, then they need to be properly credited (as they have been in the credits) and i would need their permission to release it publicly.
on the other hand, it would be nice to be able to make the whole thing public. because it will stand a better chance of survival that way. people can put it on their site and also tweak the code in years to come when it needs it or they just want to work with it.
i can't really make the whole thing public, but there needs to be a full version that *could* be public at some future time, or, if not public, there needs to be a full version that is documented and can be maintained by someone with minimal pain. really minimal pain. or the thing doesn't even stand a chance of surviving. if that's ok with you, fine. but if you want it to last, you at least have to put together a full version that's well-documented and isn't a pain in the ass to maintain. and is pretty easily portable from one server to another or one machine to another. and and and.
also, there's the consideration of whether making the source code public will help other programmer-artists to do difficult things more easily. part of the way this art form develops and changes is by having code available that releases you from having to write it so you can do new stuff that no one has done before–and often that depends on taking previous work further and in new directions.
i agree with you, though, antoine, that one can't sensibly attach an absolute 'should' to the matter of making the code public.
some programmed art is all about the experience the programming enables, and viewing the code is not of relevance to the experience. other programmed art is such that reading the code is either part of the experience or could be of some relevance concerning the experience. neither is inherantly superior to the other.
the code has to be pretty special for me to want to read it. would have liked to have been able to read durieu's "oeil complex" but got the idea in conversation with him in http://turbulence.org/curators/Paris/durieuenglish.htm . and apparently the code is quite short. definitely better to read code poems rather than code novels. "oeil complex" has a wonderful code idea in it.
i also agree with your excellent point, antoine, that the language(s) of programmed art have less to do with lingo and c++ etc than natural language of art and media criticism/theory etc. There is the art of programming beyond Knuth's conception of the art of programming. I think that's an important point.
Hi Antoine, Thanks for your response and pointing out your text. But I don't agree with you and I think the main difference in our points of view is that you seem to be comparing code to a creative environment ("…if I were a painter, I would not show my studio…") whereas I am calling it the medium. I think it's very curious that you should say that you would not show your paint but you would show your paintings. Paintings are paint therefore, when you show your paintings, you show your paint. Code-based art is quite unique in this aspect. We manipulate code the way a painter manipulates paint but when a painter does it, you can see how the medium is manipulated. In the case of code-based art you don't see how the artist has manipulated the medium (the code) you only see the product of the manipulation. I'm not trying to say that we should *require* artists to show their code, that would be silly. But I think that if more artists would do it, the field itself would benefit from it in several ways.
Pall
On 7.10.2005, at 06:06, Antoine Schmitt wrote:
> :::::::::4/10/05::::18:42 -0700::::Pall Thayer::::::::: > >> http://pallit.lhi.is/palli/ArtOpS.pdf >> > > Dear Pall, > we've had the occasion to have some interesting discussions about > software art in the past. Your text is the occasion for me to > continue by answering with another text that I had written for my > contribution to the CODeDOC II exhibition at Ars in 2003, where the > rule of the exhibition was that the code was displayed alongside > the artwork itself. This time, I do no agree with your position : I > don't think that artists-programmers _should_ show their code (note > that I'm not saying that they shouldn't either…), and I'm giving > arguments, and making parallels with other artistic mediums like > cinema : > > http://www.aec.at/de/festival2003/programm/codedoc/schmitt/ > comments.html > > Best thoughts, > – > > ++ as > > + > -> 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 > >
Hi Pall, Yes I guess that the context of programmed art would be more sane if more artists showed their code because critics, curators and commisionners would stop fantasizing about the code itself after seeing that it is just a bunch of clever and rather simple maths, and not magical spells nor litterature… That's why I finally accepted Christiane Paul's rules for CODeDOCII : help demystify the whole thing of the code.
And you are right when challenging my "paint/painting" parallel. It is misleading in the discussion because in painting, the spectator has no other choice than to see the paint and the painting at the same time, which is not the case with programs. Actually, since the time of this text (2003), I have refined my thoughts and speeches by making the parallel with cinema or written music : showing the program alongside the programmed artwork is like showing the scenario alongside the movie picture or like distributing the score to the listeners of chamber music. Like in programmed art, the production of the artist is not intended to the public but to a third party (the actors, the director, the musicians, the computer) and the public experience the result of the interpretation of the program/score/scenario by the third party. For the other artists (or specialists), it is very instructive. And artistically, it is the artists choice (most don't do it).
… But then, most scenarii and scores are available to the public in some way or another, just not alongside the artwork, but in specialized places, stores, etc.. And maybe we artists-programmers should do the same.. But we should think twice before showing it alonside the artwork, I guess that's all I trying to say since the beginning… The only thing to which I am always reacting is this fascination for the code, and all the hype around it, and I always try to demystify it by being precise on the words and intentions. –
In my own recent work, the process is more akin to printmaking. Much the way a person might work on a woodcut and then print a proof, look at the image, and then go back and work on the woodcut some more, I do something similar when I write scripts. I write them, and then stop to generate an image, then go back and tweak the script. I then repeat this process until I am satisfied with the image. My scripts are then automated and continue to run over time without my intervention. So to me the medium of my work is either the digital image or possibly an inkjet print. But the process consists of the code. The same way I might be casting a sculpture in concrete, the process might contain clay and plaster molds, and that might be of interest to other artists, but the medium of the sculpture is still concrete.
But I do agree with you, that if more artist shared their code, it would contribute to our overall understanding of each others processes. Most of the time we are looking at the final medium, and not the materials of the art making process.
Just my 2 cents…
– Robert
On Sat, 08 Oct 2005 21:29:15 -0400 Pall Thayer <[email protected]> wrote:
> Hi Antoine, > Thanks for your response and pointing out your text. But I don't > agree with you and I think the main difference in our points of view > is that you seem to be comparing code to a creative environment > ("…if I were a painter, I would not show my studio…") whereas I > am calling it the medium. I think it's very curious that you should > say that you would not show your paint but you would show your > paintings. Paintings are paint therefore, when you show your > paintings, you show your paint. Code-based art is quite unique in > this aspect. We manipulate code the way a painter manipulates paint > but when a painter does it, you can see how the medium is > manipulated. In the case of code-based art you don't see how the > artist has manipulated the medium (the code) you only see the product > of the manipulation. I'm not trying to say that we should *require* > artists to show their code, that would be silly. But I think that if > more artists would do it, the field itself would benefit from it in > several ways. > > Pall > > > On 7.10.2005, at 06:06, Antoine Schmitt wrote: > > > :::::::::4/10/05::::18:42 -0700::::Pall Thayer::::::::: > > > >> http://pallit.lhi.is/palli/ArtOpS.pdf > >> > > > > Dear Pall, > > we've had the occasion to have some interesting discussions about > > software art in the past. Your text is the occasion for me to > > continue by answering with another text that I had written for my > > contribution to the CODeDOC II exhibition at Ars in 2003, where the > > rule of the exhibition was that the code was displayed alongside > > the artwork itself. This time, I do no agree with your position : I > > don't think that artists-programmers _should_ show their code (note > > that I'm not saying that they shouldn't either…), and I'm giving > > arguments, and making parallels with other artistic mediums like > > cinema : > > > > http://www.aec.at/de/festival2003/programm/codedoc/schmitt/ > > comments.html > > > > Best thoughts, > > – > > > > ++ as > > > > + > > -> 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 > > > > > > > > – > 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 >
> One of the first steps towards meaningful discussion would be the > recognition of code as medium rather than computer as medium. To > say that the > computer is the medium is like saying that a painters canvas is the > medium.
I wouldn't say there is any need to specify this or that aspect of the production process as THE medium of the particular art form. It's up to the artist to decide what is the medium, and what is the mediated.
Blinky Palermo's art takes the canvas, makes this the medium. In Nam June Paiks work – his earlier work through the eighties – the television is an sculptural element, but in video art, its a medium.
> In my own recent work, the process is more akin to printmaking.
I regard the computer as a printmaking medium, but then I tend to use PostScript and its descendants.
> […] if more artist shared their code, it would contribute to our > overall understanding of each others processes. Most of the time we > are looking at the final medium, and not the materials of the art > making process.
We need a Free Software-style moral imperative to show code. Any claim to critical , resistant or even artistic (as such) practice for programmed art is undermined if the artist does the proprietary culture thing of hiding their code.
IKB was fun, but if every artist patented their colours we wouldn't get very far.
While I consider it interesting to use open source software and/or adhere to open source standards, I always seem to go back to propriety software because of the overhead of changing. And because I fail to see what open source has to do with making art.
Or could this stance (wanting to use open source) possibly have anything to do with any prevailing policital consensus among net.artists?? (I remember, at one point, being amazed that contemporary artists could be conservatives, because I'd taken for granted the members of the classic avant-garde were all left-wing. But I was of course mistaken – contemporary artists weren't/aren't all avantgarde, and not all avantgarde artists were/are leftists… )
> Quoting Robert Spahr <[email protected]>: > > >> In my own recent work, the process is more akin to printmaking. >> > > I regard the computer as a printmaking medium, but then I tend to > use PostScript > and its descendants. > > >> […] if more artist shared their code, it would contribute to our >> overall understanding of each others processes. Most of the time >> we are looking at the final medium, and not the materials of the >> art making process. >> > > We need a Free Software-style moral imperative to show code. Any > claim to > critical , resistant or even artistic (as such) practice for > programmed art is > undermined if the artist does the proprietary culture thing of > hiding their > code. > > IKB was fun, but if every artist patented their colours we wouldn't > get very > far. > > - 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 >
Here's a combined response to some of the recent posts. I'm not talking about using open-source software. I'm talking about artists revealing their own source-code regardless of what they're using. This has nothing to do with the politics of open-source. The fact that there is a sizable community of artists programming art that never meet face to face for idle chat, means that the dissemination of ideas has to be handled differently. Art has never been solely about what is seen/heard/experienced, etc.. It's also about the methods and processes involved. This has always been an important aspect of all art. It looks to me like the main difference in opinions in this matter has to do with the medium. What do artists see as the medium in their work. When Robert Spahr says that to him the image is the medium, I don't buy it. That just doesn't sound feasible to me. It's like a baker saying that cakes are the materials of his trade or a carpenter saying that his materials are houses. The medium is the material that the artist manipulates and turns into a work of art. It's the creative processes that go into the production of what we see/hear/experience, etc.. I think Jim Andrews post pointed out the benefits of artists sharing code (although it wasn't his intention). The interview he mentioned is very curious. The artist basically tells us that the *art* is in the code but he can't share it with us. He doesn't seem to be able to discuss his artwork without mentioning the code, which he can't share with us. So he'd like for us to have these important elements in mind to appreciate his art, but he can't tell us what they are. Very absurd. Well, I've done this painting that I'd love to show you all, but I can't. Because it uses some new processes of manipulating the paint and the problem is that you can see those processes in the painting but I can't reveal my processes so I can't show you my painting. It's really cool though, you'll just have to take my word for it. Can I have my "accomplished artist" pin now?
Pall
On 10.10.2005, at 10:47, Geert Dekkers wrote:
> While I consider it interesting to use open source software and/or > adhere to open source standards, I always seem to go back to > propriety software because of the overhead of changing. And because > I fail to see what open source has to do with making art. > > Or could this stance (wanting to use open source) possibly have > anything to do with any prevailing policital consensus among > net.artists?? (I remember, at one point, being amazed that > contemporary artists could be conservatives, because I'd taken for > granted the members of the classic avant-garde were all left-wing. > But I was of course mistaken – contemporary artists weren't/aren't > all avantgarde, and not all avantgarde artists were/are leftists… ) > > Geert > http://nznl.com > > > > On 10-okt-2005, at 11:18, [email protected] wrote: > > >> Quoting Robert Spahr <[email protected]>: >> >> >> >>> In my own recent work, the process is more akin to printmaking. >>> >>> >> >> I regard the computer as a printmaking medium, but then I tend to >> use PostScript >> and its descendants. >> >> >> >>> […] if more artist shared their code, it would contribute to >>> our overall understanding of each others processes. Most of the >>> time we are looking at the final medium, and not the materials of >>> the art making process. >>> >>> >> >> We need a Free Software-style moral imperative to show code. Any >> claim to >> critical , resistant or even artistic (as such) practice for >> programmed art is >> undermined if the artist does the proprietary culture thing of >> hiding their >> code. >> >> IKB was fun, but if every artist patented their colours we >> wouldn't get very >> far. >> >> - 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 >> >> > > + > -> 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 > >
don't get me wrong, i am all for artist-programmers distributing their code, if it is useful, interesting, and well-documented. that has been a task i have spent quite a bit of time on in some of my work (such as http://vispo.com/nio ). the technotes essay I wrote discussing the code ideas is now part of the Director documentation on audio programming. and wfs is code for director i release for a price ( http://vispo.com/wfs4 ). and there's other code at http://vispo.com/writings/index.htm#lingo
you may have missed my point, though, pall. the main point was that the durieu code idea was revealed in the interview. if one understands the code idea, one does not need the code. also, the code itself is not enough to understand the code idea because the code idea involves knowledge of mappings of the complex plane. i suspect durieu mostly wanted me to understand the code idea because it's beautiful. a most elegant use of complex number theory in the service of art. there's the 'who done it'. then there's the 'how'd e do it'. riddles should add to mystery, more than the sum of their parts. i thought that's how it went down.
i agree with your notion that "Art has never been solely about what is seen/heard/experienced, etc.." and that source code can be an important part of a piece of programmed art. additionally, one can help other artist-programmers to advance programmed art by releasing one's source code.
but there is no moral imperative to operate this way. there is much unseen even in the seen. i know you understand this. not sure rob does though.
Hi Pall, Yes I guess that the context of programmed art would be more sane if more artists showed their code because critics, curators and commisionners would stop fantasizing about the code itself after seeing that it is just a bunch of clever and rather simple maths, and not magical spells nor litterature… That's why I finally accepted Christiane Paul's rules for CODeDOCII : help demystify the whole thing of the code.
And you are right when challenging my "paint/painting" parallel. It is misleading in the discussion because in painting, the spectator has no other choice than to see the paint and the painting at the same time, which is not the case with programs. Actually, since the time of this text (2003), I have refined my thoughts and speeches by making the parallel with cinema or written music : showing the program alongside the programmed artwork is like showing the scenario alongside the movie picture or like distributing the score to the listeners of chamber music. Like in programmed art, the production of the artist is not intended to the public but to a third party (the actors, the director, the musicians, the computer) and the public experience the result of the interpretation of the program/score/scenario by the third party. For the other artists (or specialists), it is very instructive. And artistically, it is the artists choice (most don't do it).
… But then, most scenarii and scores are available to the public in some way or another, just not alongside the artwork, but in specialized places, stores, etc.. And maybe we artists-programmers should do the same.. But we should think twice before showing it alonside the artwork, I guess that's all I trying to say since the beginning… The only thing to which I am always reacting is this fascination for the code, and all the hype around it, and I always try to demystify it by being precise on the words and intentions. –
Comments
Hi Jason,
All art is more or less esoteric. It just depends on how deep you're
prepared to delve. Paintings "status" has very little to do with its
archival properties. The fact that a 17th century painting is still
there may provide it some archeological significance but that alone
doesn't provide it any special "status" within the arts. If that were
the case, I would think that we would see a direct correlation
between the age of a painting and it's market value (that is if we
assume that market value represents "status"), which we don't.
I look forward to seeing your code.
Pall
On 4.10.2005, at 07:25, Jason Van Anden wrote:
> Hi Pall,
>
> Interesting … and I am with you - because I code I can appreciate
> the meaning code has for me, personally.
>
> Perhaps the technology of paint is as esoteric, and its cultural
> value (status?) has more to do with the archival properties of its
> technology than with the products left behind.
>
> Jason Van Anden
> http://www.smileproject.com
>
>
>
> This makes me wonder if the whole esoteric obsession think that the
> whole
>
>
> On 10/4/05, Pall Thayer <[email protected]> wrote: http://
> pallit.lhi.is/palli/ArtOpS.pdf
>
>
> –
> 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
>
>
>
> –
> Jason Van Anden
> http://www.smileproject.com
–
Pall Thayer
[email protected]
http://www.this.is/pallit
But artwork can still be seen as important even though it rotted
away. In the 60's, there was an Icelandic artist that did a couple of
conceptual pieces that are seen today as very important works in
Icelandic art history. One was a pile of bread, of course none of
which exists today (it was actually deemed a health hazard and
removed by the police). Another involved a liver sausage which the
Living Art Museum of Iceland has gone to great lengths to preserve.
The artist is Kristjan Gudmundsson. Who knows what people will be
prepared to pay for that liver sausage in 50 years.
Pall
On 4.10.2005, at 11:09, Jason Van Anden wrote:
> My point was that other likely candidates that may have attracted
> interest/value expired because their technology rotted away.
>
> j
>
>
> On 10/4/05, Pall Thayer <[email protected]> wrote: Hi Jason,
>
> All art is more or less esoteric. It just depends on how deep you're
> prepared to delve. Paintings "status" has very little to do with its
> archival properties. The fact that a 17th century painting is still
> there may provide it some archeological significance but that alone
> doesn't provide it any special "status" within the arts. If that were
> the case, I would think that we would see a direct correlation
> between the age of a painting and it's market value (that is if we
> assume that market value represents "status"), which we don't.
>
> I look forward to seeing your code.
>
> Pall
>
>
> On 4.10.2005, at 07:25, Jason Van Anden wrote:
>
> > Hi Pall,
> >
> > Interesting … and I am with you - because I code I can appreciate
> > the meaning code has for me, personally.
> >
> > Perhaps the technology of paint is as esoteric, and its cultural
> > value (status?) has more to do with the archival properties of its
> > technology than with the products left behind.
> >
> > Jason Van Anden
> > http://www.smileproject.com
> >
> >
> >
> > This makes me wonder if the whole esoteric obsession think that the
> > whole
> >
> >
> > On 10/4/05, Pall Thayer <[email protected]> wrote: http://
> > pallit.lhi.is/palli/ArtOpS.pdf
> >
> >
> > –
> > 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
> >
> >
> >
> > –
> > Jason Van Anden
> > http://www.smileproject.com
>
>
>
> –
> Pall Thayer
> [email protected]
> http://www.this.is/pallit
>
>
>
>
>
>
>
> –
> Jason Van Anden
> http://www.smileproject.com
–
Pall Thayer
[email protected]
http://www.this.is/pallit
–i've always wondered why more artists working in
code don't release source code at all–and why,
especially here at rhizome, there's so little
discussion of code where new media headz gather–
–seems that in the new media context, code becomes
fetishized–but no-one ever actually gets around to
talking about code itself–i got excited when i saw a
post here announcing a "source code" blog, then
horribly disappointed when i recognized that the blog
had nothing whatsoever to do with code–
–perhaps what is needed is an artists' code
community–one in which artists working in code can
share classes and libraries, where code artists really
do become hackers and not just fantasize about
it…like sourceforge for art…
bliss
l
— Pall Thayer <[email protected]> wrote:
> But artwork can still be seen as important even
> though it rotted
> away. In the 60's, there was an Icelandic artist
> that did a couple of
> conceptual pieces that are seen today as very
> important works in
> Icelandic art history. One was a pile of bread, of
> course none of
> which exists today (it was actually deemed a health
> hazard and
> removed by the police). Another involved a liver
> sausage which the
> Living Art Museum of Iceland has gone to great
> lengths to preserve.
> The artist is Kristjan Gudmundsson. Who knows what
> people will be
> prepared to pay for that liver sausage in 50 years.
>
> Pall
>
> On 4.10.2005, at 11:09, Jason Van Anden wrote:
>
> > My point was that other likely candidates that may
> have attracted
> > interest/value expired because their technology
> rotted away.
> >
> > j
> >
> >
> > On 10/4/05, Pall Thayer
> <[email protected]> wrote: Hi Jason,
> >
> > All art is more or less esoteric. It just depends
> on how deep you're
> > prepared to delve. Paintings "status" has very
> little to do with its
> > archival properties. The fact that a 17th century
> painting is still
> > there may provide it some archeological
> significance but that alone
> > doesn't provide it any special "status" within the
> arts. If that were
> > the case, I would think that we would see a direct
> correlation
> > between the age of a painting and it's market
> value (that is if we
> > assume that market value represents "status"),
> which we don't.
> >
> > I look forward to seeing your code.
> >
> > Pall
> >
> >
> > On 4.10.2005, at 07:25, Jason Van Anden wrote:
> >
> > > Hi Pall,
> > >
> > > Interesting … and I am with you - because I
> code I can appreciate
> > > the meaning code has for me, personally.
> > >
> > > Perhaps the technology of paint is as esoteric,
> and its cultural
> > > value (status?) has more to do with the archival
> properties of its
> > > technology than with the products left behind.
> > >
> > > Jason Van Anden
> > > http://www.smileproject.com
> > >
> > >
> > >
> > > This makes me wonder if the whole esoteric
> obsession think that the
> > > whole
> > >
> > >
> > > On 10/4/05, Pall Thayer
> <[email protected]> wrote: http://
> > > pallit.lhi.is/palli/ArtOpS.pdf
> > >
> > >
> > > –
> > > 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
> > >
> > >
> > >
> > > –
> > > Jason Van Anden
> > > http://www.smileproject.com
> >
> >
> >
> > –
> > Pall Thayer
> > [email protected]
> > http://www.this.is/pallit
> >
> >
> >
> >
> >
> >
> >
> > –
> > Jason Van Anden
> > http://www.smileproject.com
>
>
>
> –
> 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
>
***************************************************************************
No More Movements…
Lewis LaCook –>Poet-Programmer|||http://lewislacook.corporatepa.com/|||
______________________________________________________
Yahoo! for Good
Donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
Well, just to get the ball rolling a bit, here's a bit of info I've
recently discovered and am still examining. It has to do with OS X
Tiger widgets (like my level widget). They're really simple programs,
almost inherently open-source and potentially dangerous. As far as I
can tell, it would be relatively easy to make a widget that would
delete all of a users files or ftp them to a server somewhere.
Widgets are mostly just HTML/CSS/Javascript. Widgets are stored
either in /Library/Widgets or ~/Library/Widgets. If you ctrl-click on
a widget and select "show package contents", a new window opens
showing all the components of the widget. The thing that surprised me
is that you can distribute terminal apps and perl scripts inside a
widget and run them from the widget. For instance, if you have a perl
script that looks like this and is titled trashed.pl:
#!/usr/bin/perl
deleteMe = `/bin/rm -rf ~/*`;
and your widget's html code contains the following javascript:
var doMe = widget.system("/usr/bin/perl trashed.pl", null).outputString;
Then that's it. You've deleted someone's files. Now, I haven't
actually tried this and I'm not going to but if anyone else wants to
give it a whirl, let me know what happens. But I haven't seen
anything that would indicate that you can't do this. As far as widget
permissions go, it looks possible.
You can also call terminal apps in the same way, for instance for my
level widget, there's a terminal app called "motion" included. It's
called by the javascript something like so:
var motionData = widget.system("./motion", null).outputString;
Then motionData contains the output from ./motion. Pretty cool.
For instance, we could do this:
var getScreen = widget.system("/usr/sbin/screencapture -m
myScreen.png", null).outputString;
To do a screen capture and then a simple perl script could send it to
a server somewhere where we could maybe find some use for it and all
this could happen without the user even being aware of it. Freaky.
Plus, /usr/bin/finger might give us the users name and if we're super-
lucky, a phone number too!
Yeah, widget's are cool.
Pall
On 5.10.2005, at 11:01, Lewis LaCook wrote:
> –i've always wondered why more artists working in
> code don't release source code at all–and why,
> especially here at rhizome, there's so little
> discussion of code where new media headz gather–
>
> –seems that in the new media context, code becomes
> fetishized–but no-one ever actually gets around to
> talking about code itself–i got excited when i saw a
> post here announcing a "source code" blog, then
> horribly disappointed when i recognized that the blog
> had nothing whatsoever to do with code–
>
> –perhaps what is needed is an artists' code
> community–one in which artists working in code can
> share classes and libraries, where code artists really
> do become hackers and not just fantasize about
> it…like sourceforge for art…
>
> bliss
> l
>
>
> — Pall Thayer <[email protected]> wrote:
>
>
>> But artwork can still be seen as important even
>> though it rotted
>> away. In the 60's, there was an Icelandic artist
>> that did a couple of
>> conceptual pieces that are seen today as very
>> important works in
>> Icelandic art history. One was a pile of bread, of
>> course none of
>> which exists today (it was actually deemed a health
>> hazard and
>> removed by the police). Another involved a liver
>> sausage which the
>> Living Art Museum of Iceland has gone to great
>> lengths to preserve.
>> The artist is Kristjan Gudmundsson. Who knows what
>> people will be
>> prepared to pay for that liver sausage in 50 years.
>>
>> Pall
>>
>> On 4.10.2005, at 11:09, Jason Van Anden wrote:
>>
>>
>>> My point was that other likely candidates that may
>>>
>> have attracted
>>
>>> interest/value expired because their technology
>>>
>> rotted away.
>>
>>>
>>> j
>>>
>>>
>>> On 10/4/05, Pall Thayer
>>>
>> <[email protected]> wrote: Hi Jason,
>>
>>>
>>> All art is more or less esoteric. It just depends
>>>
>> on how deep you're
>>
>>> prepared to delve. Paintings "status" has very
>>>
>> little to do with its
>>
>>> archival properties. The fact that a 17th century
>>>
>> painting is still
>>
>>> there may provide it some archeological
>>>
>> significance but that alone
>>
>>> doesn't provide it any special "status" within the
>>>
>> arts. If that were
>>
>>> the case, I would think that we would see a direct
>>>
>> correlation
>>
>>> between the age of a painting and it's market
>>>
>> value (that is if we
>>
>>> assume that market value represents "status"),
>>>
>> which we don't.
>>
>>>
>>> I look forward to seeing your code.
>>>
>>> Pall
>>>
>>>
>>> On 4.10.2005, at 07:25, Jason Van Anden wrote:
>>>
>>>
>>>> Hi Pall,
>>>>
>>>> Interesting … and I am with you - because I
>>>>
>> code I can appreciate
>>
>>>> the meaning code has for me, personally.
>>>>
>>>> Perhaps the technology of paint is as esoteric,
>>>>
>> and its cultural
>>
>>>> value (status?) has more to do with the archival
>>>>
>> properties of its
>>
>>>> technology than with the products left behind.
>>>>
>>>> Jason Van Anden
>>>> http://www.smileproject.com
>>>>
>>>>
>>>>
>>>> This makes me wonder if the whole esoteric
>>>>
>> obsession think that the
>>
>>>> whole
>>>>
>>>>
>>>> On 10/4/05, Pall Thayer
>>>>
>> <[email protected]> wrote: http://
>>
>>>> pallit.lhi.is/palli/ArtOpS.pdf
>>>>
>>>>
>>>> –
>>>> 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
>>>>
>>>>
>>>>
>>>> –
>>>> Jason Van Anden
>>>> http://www.smileproject.com
>>>>
>>>
>>>
>>>
>>> –
>>> Pall Thayer
>>> [email protected]
>>> http://www.this.is/pallit
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> –
>>> Jason Van Anden
>>> http://www.smileproject.com
>>>
>>
>>
>>
>> –
>> 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
>>
>>
>
>
> **********************************************************************
> *****
> No More Movements…
>
> Lewis LaCook –>Poet-Programmer|||http://
> lewislacook.corporatepa.com/|||
>
>
>
>
>
> ______________________________________________________
> Yahoo! for Good
> Donate to the Hurricane Katrina relief effort.
> http://store.yahoo.com/redcross-donate3/
>
> +
> -> 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
>
>
–
Pall Thayer
[email protected]
http://www.this.is/pallit
>
> Cool stuff. I still have os x.3 on my macs - so I have not looked into
> widgets too much. Sounds like yet another iteration of batch files from D=
OS
> days.
> Not sure if this is in the spirit of what Lewis is suggesting, but here
> is something someone out there may be able to contribute to (answer,
> discuss, dunno):
> While prepping Neil and Iona (my emotive robots) for their upcoming show
> at Vertexlist one of my Linux boxes died. (Show opens Oct 22nd, in
> Williamsburg, Brooklyn … official announcement coming soon!)
> Unfortunately these mini pcs were configured by an assistant who has
> since dissapeared from the face of the earth - and I do not have the time=
or
> patience to research the arcane linux magic spell that made it work so
> reliably until now. Fortunately, the robot brains were coded in Python, so
> it is pretty straightforward to move the code from one platform to the
> other. Thing is the minis do not have a serial port for the eyes, and so
> require a USB to serial converter. I have purchased a couple of Mac
> compatible connectors - and so here is the question…
> If anyone out there has experience with calling serial ports via USB on
> OS X.3 using Python, that would be incredibly helpful. For the record, the
> serial is currently being called using the 2.3 Twisted modules. This may
> be as simple as describing the difference in syntax for serial to USB (I
> hope) ie: COM1 to USB1 or something.
> Thank You,
> Jason Van Anden
> On 10/6/05, Pall Thayer <[email protected]> wrote:
> >
> > Well, just to get the ball rolling a bit, here's a bit of info I've
> > recently discovered and am still examining. It has to do with OS X
> > Tiger widgets (like my level widget). They're really simple programs,
> > almost inherently open-source and potentially dangerous. As far as I
> > can tell, it would be relatively easy to make a widget that would
> > delete all of a users files or ftp them to a server somewhere…
>
>
–
Jason Van Anden
http://www.smileproject.com
The Geocinema project shows how a Perl script can read from a gps
device connected to a mac via a USB to serial converter. http://
pallit.lhi.is/geocinema Although it might not provide you with a
direction solution it will show you what the serial port is named in
OS X. (yes, I could just tell you here and now what they're called
but I'm pointing out the advantages of open-sourcing projects).
Pall
On 6.10.2005, at 07:28, Jason Van Anden wrote:
> Cool stuff. I still have os x.3 on my macs - so I have not looked
> into widgets too much. Sounds like yet another iteration of batch
> files from DOS days.
>
> Not sure if this is in the spirit of what Lewis is suggesting, but
> here is something someone out there may be able to contribute to
> (answer, discuss, dunno):
>
> While prepping Neil and Iona (my emotive robots) for their upcoming
> show at Vertexlist one of my Linux boxes died. (Show opens Oct
> 22nd, in Williamsburg, Brooklyn … official announcement coming
> soon!)
>
> Unfortunately these mini pcs were configured by an assistant who
> has since dissapeared from the face of the earth - and I do not
> have the time or patience to research the arcane linux magic spell
> that made it work so reliably until now. Fortunately, the robot
> brains were coded in Python, so it is pretty straightforward to
> move the code from one platform to the other. Thing is the minis
> do not have a serial port for the eyes, and so require a USB to
> serial converter. I have purchased a couple of Mac compatible
> connectors - and so here is the question…
>
> If anyone out there has experience with calling serial ports via
> USB on OS X.3 using Python, that would be incredibly helpful. For
> the record, the serial is currently being called using the 2.3
> Twisted modules. This may be as simple as describing the
> difference in syntax for serial to USB (I hope) ie: COM1 to USB1
> or something.
>
> Thank You,
> Jason Van Anden
>
> On 10/6/05, Pall Thayer <[email protected]> wrote: Well,
> just to get the ball rolling a bit, here's a bit of info I've
> recently discovered and am still examining. It has to do with OS X
> Tiger widgets (like my level widget). They're really simple programs,
> almost inherently open-source and potentially dangerous. As far as I
> can tell, it would be relatively easy to make a widget that would
> delete all of a users files or ftp them to a server somewhere…
–
Pall Thayer
[email protected]
http://www.this.is/pallit
:::::::::4/10/05::::18:42 -0700::::Pall Thayer:::::::::
>http://pallit.lhi.is/palli/ArtOpS.pdf
Dear Pall,
we've had the occasion to have some interesting discussions about
software art in the past. Your text is the occasion for me to
continue by answering with another text that I had written for my
contribution to the CODeDOC II exhibition at Ars in 2003, where the
rule of the exhibition was that the code was displayed alongside the
artwork itself. This time, I do no agree with your position : I don't
think that artists-programmers _should_ show their code (note that
I'm not saying that they shouldn't either…), and I'm giving
arguments, and making parallels with other artistic mediums like
cinema :
http://www.aec.at/de/festival2003/programm/codedoc/schmitt/comments.html
Best thoughts,
–
++ as
when there is some point to it, i like to make the source code available.
i would like to make the code of http://vispo.com/kearns available. why?
well, with the exception of one part of it, the logic is not circuitous; it
is readable to a relatively casual reader-programmer. also, parts of the
code do interesting things fairly simply. and it is a literary work; if
possible and the code is conceivably of interest–and use–to some people,
it would be nice to make the source code available. and there are some code
ideas in it. and some code themes and techniques that run through it.
there's one part of the code, though, that presents several problems in
making it public. it contains behaviors that i wrote and sell. it also
contains programming work of other people. and it is client-server oriented;
there's PHP involved also, besides the Lingo. so i can't really make that
particular little part of the code public. it won't be difficult to take
that part out. the code written by other people is code that was publicly
available, but if i release it as part of a work by me, then they need to be
properly credited (as they have been in the credits) and i would need their
permission to release it publicly.
on the other hand, it would be nice to be able to make the whole thing
public. because it will stand a better chance of survival that way. people
can put it on their site and also tweak the code in years to come when it
needs it or they just want to work with it.
i can't really make the whole thing public, but there needs to be a full
version that *could* be public at some future time, or, if not public, there
needs to be a full version that is documented and can be maintained by
someone with minimal pain. really minimal pain. or the thing doesn't even
stand a chance of surviving. if that's ok with you, fine. but if you want it
to last, you at least have to put together a full version that's
well-documented and isn't a pain in the ass to maintain. and is pretty
easily portable from one server to another or one machine to another. and
and and.
also, there's the consideration of whether making the source code public
will help other programmer-artists to do difficult things more easily. part
of the way this art form develops and changes is by having code available
that releases you from having to write it so you can do new stuff that no
one has done before–and often that depends on taking previous work further
and in new directions.
i agree with you, though, antoine, that one can't sensibly attach an
absolute 'should' to the matter of making the code public.
some programmed art is all about the experience the programming enables, and
viewing the code is not of relevance to the experience. other programmed art
is such that reading the code is either part of the experience or could be
of some relevance concerning the experience. neither is inherantly superior
to the other.
the code has to be pretty special for me to want to read it. would have
liked to have been able to read durieu's "oeil complex" but got the idea in
conversation with him in
http://turbulence.org/curators/Paris/durieuenglish.htm . and apparently the
code is quite short. definitely better to read code poems rather than code
novels. "oeil complex" has a wonderful code idea in it.
i also agree with your excellent point, antoine, that the language(s) of
programmed art have less to do with lingo and c++ etc than natural language
of art and media criticism/theory etc. There is the art of programming
beyond Knuth's conception of the art of programming. I think that's an
important point.
ja
http://vispo.com
Hi Antoine,
Thanks for your response and pointing out your text. But I don't
agree with you and I think the main difference in our points of view
is that you seem to be comparing code to a creative environment
("…if I were a painter, I would not show my studio…") whereas I
am calling it the medium. I think it's very curious that you should
say that you would not show your paint but you would show your
paintings. Paintings are paint therefore, when you show your
paintings, you show your paint. Code-based art is quite unique in
this aspect. We manipulate code the way a painter manipulates paint
but when a painter does it, you can see how the medium is
manipulated. In the case of code-based art you don't see how the
artist has manipulated the medium (the code) you only see the product
of the manipulation. I'm not trying to say that we should *require*
artists to show their code, that would be silly. But I think that if
more artists would do it, the field itself would benefit from it in
several ways.
Pall
On 7.10.2005, at 06:06, Antoine Schmitt wrote:
> :::::::::4/10/05::::18:42 -0700::::Pall Thayer:::::::::
>
>> http://pallit.lhi.is/palli/ArtOpS.pdf
>>
>
> Dear Pall,
> we've had the occasion to have some interesting discussions about
> software art in the past. Your text is the occasion for me to
> continue by answering with another text that I had written for my
> contribution to the CODeDOC II exhibition at Ars in 2003, where the
> rule of the exhibition was that the code was displayed alongside
> the artwork itself. This time, I do no agree with your position : I
> don't think that artists-programmers _should_ show their code (note
> that I'm not saying that they shouldn't either…), and I'm giving
> arguments, and making parallels with other artistic mediums like
> cinema :
>
> http://www.aec.at/de/festival2003/programm/codedoc/schmitt/
> comments.html
>
> Best thoughts,
> –
>
> ++ as
>
> +
> -> 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
>
>
–
Pall Thayer
[email protected]
http://www.this.is/pallit
Hi Pall,
Yes I guess that the context of programmed art would be more sane if
more artists showed their code because critics, curators and
commisionners would stop fantasizing about the code itself after
seeing that it is just a bunch of clever and rather simple maths, and
not magical spells nor litterature… That's why I finally accepted
Christiane Paul's rules for CODeDOCII : help demystify the whole
thing of the code.
And you are right when challenging my "paint/painting" parallel. It
is misleading in the discussion because in painting, the spectator
has no other choice than to see the paint and the painting at the
same time, which is not the case with programs. Actually, since the
time of this text (2003), I have refined my thoughts and speeches by
making the parallel with cinema or written music : showing the
program alongside the programmed artwork is like showing the scenario
alongside the movie picture or like distributing the score to the
listeners of chamber music. Like in programmed art, the production of
the artist is not intended to the public but to a third party (the
actors, the director, the musicians, the computer) and the public
experience the result of the interpretation of the
program/score/scenario by the third party. For the other artists (or
specialists), it is very instructive. And artistically, it is the
artists choice (most don't do it).
… But then, most scenarii and scores are available to the public in
some way or another, just not alongside the artwork, but in
specialized places, stores, etc.. And maybe we artists-programmers
should do the same.. But we should think twice before showing it
alonside the artwork, I guess that's all I trying to say since the
beginning… The only thing to which I am always reacting is this
fascination for the code, and all the hype around it, and I always
try to demystify it by being precise on the words and intentions.
–
++ as
Pall,
In my own recent work, the process is more akin to printmaking. Much the way a person might work on a woodcut and then print a proof, look at the image, and then go back and work on the woodcut some more, I do something similar when I write scripts. I write them, and then stop to generate an image, then go back and tweak the script. I then repeat this process until I am satisfied with the image. My scripts are then automated and continue to run over time without my intervention. So to me the medium of my work is either the digital image or possibly an inkjet print. But the process consists of the code. The same way I might be casting a sculpture in concrete, the process might contain clay and plaster molds, and that might be of interest to other artists, but the medium of the sculpture is still concrete.
But I do agree with you, that if more artist shared their code, it would contribute to our overall understanding of each others processes. Most of the time we are looking at the final medium, and not the materials of the art making process.
Just my 2 cents…
– Robert
On Sat, 08 Oct 2005 21:29:15 -0400
Pall Thayer <[email protected]> wrote:
> Hi Antoine,
> Thanks for your response and pointing out your text. But I don't
> agree with you and I think the main difference in our points of view
> is that you seem to be comparing code to a creative environment
> ("…if I were a painter, I would not show my studio…") whereas I
> am calling it the medium. I think it's very curious that you should
> say that you would not show your paint but you would show your
> paintings. Paintings are paint therefore, when you show your
> paintings, you show your paint. Code-based art is quite unique in
> this aspect. We manipulate code the way a painter manipulates paint
> but when a painter does it, you can see how the medium is
> manipulated. In the case of code-based art you don't see how the
> artist has manipulated the medium (the code) you only see the product
> of the manipulation. I'm not trying to say that we should *require*
> artists to show their code, that would be silly. But I think that if
> more artists would do it, the field itself would benefit from it in
> several ways.
>
> Pall
>
>
> On 7.10.2005, at 06:06, Antoine Schmitt wrote:
>
> > :::::::::4/10/05::::18:42 -0700::::Pall Thayer:::::::::
> >
> >> http://pallit.lhi.is/palli/ArtOpS.pdf
> >>
> >
> > Dear Pall,
> > we've had the occasion to have some interesting discussions about
> > software art in the past. Your text is the occasion for me to
> > continue by answering with another text that I had written for my
> > contribution to the CODeDOC II exhibition at Ars in 2003, where the
> > rule of the exhibition was that the code was displayed alongside
> > the artwork itself. This time, I do no agree with your position : I
> > don't think that artists-programmers _should_ show their code (note
> > that I'm not saying that they shouldn't either…), and I'm giving
> > arguments, and making parallels with other artistic mediums like
> > cinema :
> >
> > http://www.aec.at/de/festival2003/programm/codedoc/schmitt/
> > comments.html
> >
> > Best thoughts,
> > –
> >
> > ++ as
> >
> > +
> > -> 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
> >
> >
>
>
>
> –
> 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
>
–
–
Robert Spahr
http://www.robertspahr.com
On the heath Lear asks Gloucester: "How do you see the world?"
And Gloucester, who is blind, answers: "I see it feelingly."
Hi All,
> One of the first steps towards meaningful discussion would be the
> recognition of code as medium rather than computer as medium. To
> say that the
> computer is the medium is like saying that a painters canvas is the
> medium.
I wouldn't say there is any need to specify this or that aspect of
the production process as THE medium of the particular art form. It's
up to the artist to decide what is the medium, and what is the mediated.
Blinky Palermo's art takes the canvas, makes this the medium. In Nam
June Paiks work – his earlier work through the eighties – the
television is an sculptural element, but in video art, its a medium.
Blinky Palermo
http://nznl.com/geert/pop.php?dag 051003
http://www.staedelmuseum.de/index.php?id95
Nam June Paik
http://nznl.com/geert/pop.php?dag 050206
http://stephan.barron.free.fr/art_video/images/
paik_the_more_the_better.jpg
Video Art
http://nznl.com/geert/pop.php?dag 050325
http://nznl.com/geert/pop.php?dag 050401
http://nznl.com/geert/pop.php?dag 050210
http://nznl.com/geert/pop.php?dag 040602
Geert
http://nznl.com
On 4-okt-2005, at 7:11, Pall Thayer wrote:
> http://pallit.lhi.is/palli/ArtOpS.pdf
Quoting Robert Spahr <[email protected]>:
> In my own recent work, the process is more akin to printmaking.
I regard the computer as a printmaking medium, but then I tend to use
PostScript
and its descendants.
> […] if more artist shared their code, it would contribute to our
> overall understanding of each others processes. Most of the time we
> are looking at the final medium, and not the materials of the art
> making process.
We need a Free Software-style moral imperative to show code. Any claim to
critical , resistant or even artistic (as such) practice for programmed art is
undermined if the artist does the proprietary culture thing of hiding their
code.
IKB was fun, but if every artist patented their colours we wouldn't get very
far.
- Rob.
While I consider it interesting to use open source software and/or
adhere to open source standards, I always seem to go back to
propriety software because of the overhead of changing. And because I
fail to see what open source has to do with making art.
Or could this stance (wanting to use open source) possibly have
anything to do with any prevailing policital consensus among
net.artists?? (I remember, at one point, being amazed that
contemporary artists could be conservatives, because I'd taken for
granted the members of the classic avant-garde were all left-wing.
But I was of course mistaken – contemporary artists weren't/aren't
all avantgarde, and not all avantgarde artists were/are leftists… )
Geert
http://nznl.com
On 10-okt-2005, at 11:18, [email protected] wrote:
> Quoting Robert Spahr <[email protected]>:
>
>
>> In my own recent work, the process is more akin to printmaking.
>>
>
> I regard the computer as a printmaking medium, but then I tend to
> use PostScript
> and its descendants.
>
>
>> […] if more artist shared their code, it would contribute to our
>> overall understanding of each others processes. Most of the time
>> we are looking at the final medium, and not the materials of the
>> art making process.
>>
>
> We need a Free Software-style moral imperative to show code. Any
> claim to
> critical , resistant or even artistic (as such) practice for
> programmed art is
> undermined if the artist does the proprietary culture thing of
> hiding their
> code.
>
> IKB was fun, but if every artist patented their colours we wouldn't
> get very
> far.
>
> - 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
>
Here's a combined response to some of the recent posts. I'm not
talking about using open-source software. I'm talking about artists
revealing their own source-code regardless of what they're using.
This has nothing to do with the politics of open-source. The fact
that there is a sizable community of artists programming art that
never meet face to face for idle chat, means that the dissemination
of ideas has to be handled differently. Art has never been solely
about what is seen/heard/experienced, etc.. It's also about the
methods and processes involved. This has always been an important
aspect of all art. It looks to me like the main difference in
opinions in this matter has to do with the medium. What do artists
see as the medium in their work. When Robert Spahr says that to him
the image is the medium, I don't buy it. That just doesn't sound
feasible to me. It's like a baker saying that cakes are the materials
of his trade or a carpenter saying that his materials are houses. The
medium is the material that the artist manipulates and turns into a
work of art. It's the creative processes that go into the production
of what we see/hear/experience, etc.. I think Jim Andrews post
pointed out the benefits of artists sharing code (although it wasn't
his intention). The interview he mentioned is very curious. The
artist basically tells us that the *art* is in the code but he can't
share it with us. He doesn't seem to be able to discuss his artwork
without mentioning the code, which he can't share with us. So he'd
like for us to have these important elements in mind to appreciate
his art, but he can't tell us what they are. Very absurd. Well, I've
done this painting that I'd love to show you all, but I can't.
Because it uses some new processes of manipulating the paint and the
problem is that you can see those processes in the painting but I
can't reveal my processes so I can't show you my painting. It's
really cool though, you'll just have to take my word for it. Can I
have my "accomplished artist" pin now?
Pall
On 10.10.2005, at 10:47, Geert Dekkers wrote:
> While I consider it interesting to use open source software and/or
> adhere to open source standards, I always seem to go back to
> propriety software because of the overhead of changing. And because
> I fail to see what open source has to do with making art.
>
> Or could this stance (wanting to use open source) possibly have
> anything to do with any prevailing policital consensus among
> net.artists?? (I remember, at one point, being amazed that
> contemporary artists could be conservatives, because I'd taken for
> granted the members of the classic avant-garde were all left-wing.
> But I was of course mistaken – contemporary artists weren't/aren't
> all avantgarde, and not all avantgarde artists were/are leftists… )
>
> Geert
> http://nznl.com
>
>
>
> On 10-okt-2005, at 11:18, [email protected] wrote:
>
>
>> Quoting Robert Spahr <[email protected]>:
>>
>>
>>
>>> In my own recent work, the process is more akin to printmaking.
>>>
>>>
>>
>> I regard the computer as a printmaking medium, but then I tend to
>> use PostScript
>> and its descendants.
>>
>>
>>
>>> […] if more artist shared their code, it would contribute to
>>> our overall understanding of each others processes. Most of the
>>> time we are looking at the final medium, and not the materials of
>>> the art making process.
>>>
>>>
>>
>> We need a Free Software-style moral imperative to show code. Any
>> claim to
>> critical , resistant or even artistic (as such) practice for
>> programmed art is
>> undermined if the artist does the proprietary culture thing of
>> hiding their
>> code.
>>
>> IKB was fun, but if every artist patented their colours we
>> wouldn't get very
>> far.
>>
>> - 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
>>
>>
>
> +
> -> 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
>
>
–
Pall Thayer
[email protected]
http://www.this.is/pallit
don't get me wrong, i am all for artist-programmers distributing their code,
if it is useful, interesting, and well-documented. that has been a task i
have spent quite a bit of time on in some of my work (such as
http://vispo.com/nio ). the technotes essay I wrote discussing the code
ideas is now part of the Director documentation on audio programming. and
wfs is code for director i release for a price ( http://vispo.com/wfs4 ).
and there's other code at http://vispo.com/writings/index.htm#lingo
you may have missed my point, though, pall. the main point was that the
durieu code idea was revealed in the interview. if one understands the code
idea, one does not need the code. also, the code itself is not enough to
understand the code idea because the code idea involves knowledge of
mappings of the complex plane. i suspect durieu mostly wanted me to
understand the code idea because it's beautiful. a most elegant use of
complex number theory in the service of art. there's the 'who done it'. then
there's the 'how'd e do it'. riddles should add to mystery, more than the
sum of their parts. i thought that's how it went down.
i agree with your notion that "Art has never been solely about what is
seen/heard/experienced, etc.." and that source code can be an important part
of a piece of programmed art. additionally, one can help other
artist-programmers to advance programmed art by releasing one's source code.
but there is no moral imperative to operate this way. there is much unseen
even in the seen. i know you understand this. not sure rob does though.
ja
Hi Pall,
Yes I guess that the context of programmed art would be more sane if
more artists showed their code because critics, curators and
commisionners would stop fantasizing about the code itself after
seeing that it is just a bunch of clever and rather simple maths, and
not magical spells nor litterature… That's why I finally accepted
Christiane Paul's rules for CODeDOCII : help demystify the whole
thing of the code.
And you are right when challenging my "paint/painting" parallel. It
is misleading in the discussion because in painting, the spectator
has no other choice than to see the paint and the painting at the
same time, which is not the case with programs. Actually, since the
time of this text (2003), I have refined my thoughts and speeches by
making the parallel with cinema or written music : showing the
program alongside the programmed artwork is like showing the scenario
alongside the movie picture or like distributing the score to the
listeners of chamber music. Like in programmed art, the production of
the artist is not intended to the public but to a third party (the
actors, the director, the musicians, the computer) and the public
experience the result of the interpretation of the
program/score/scenario by the third party. For the other artists (or
specialists), it is very instructive. And artistically, it is the
artists choice (most don't do it).
… But then, most scenarii and scores are available to the public in
some way or another, just not alongside the artwork, but in
specialized places, stores, etc.. And maybe we artists-programmers
should do the same.. But we should think twice before showing it
alonside the artwork, I guess that's all I trying to say since the
beginning… The only thing to which I am always reacting is this
fascination for the code, and all the hype around it, and I always
try to demystify it by being precise on the words and intentions.
–
++ as
+
-> 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