Re: [-empyre-] Re: empyre Digest, Vol 12, Issue 26



What does one need to run processing?  (I mean on the web server...)  I have
access to the Java Runtime Environment on my server, but I haven't used it
yet,  But I can't run programs which need to communicate via a port, ie
socket servers for multiuser applications.  I looked a little at the
processing website, and they say that  their language runs over Java.  Can
it be installed on a linux server?  Would I need to be the sysadmin to
install it?  (Obviously I'm not; it's a shared web hosting situation...)

Millie
----- Original Message ----- 
From: "Jim Andrews" <jim@vispo.com>
To: "soft_skinned_space" <empyre@lists.cofa.unsw.edu.au>
Sent: Saturday, January 31, 2004 6:49 AM
Subject: RE: [-empyre-] Re: empyre Digest, Vol 12, Issue 26


>
> > Dear Em's and JIm
> >
> > > One of my hopes is that it will allow me to collaborate with artists
> > > who
> > > have greater visual skills are more focused on the visual --
> > > facilitating
> > > a collaboration that draws together different skills, in which
everyone
> > > can understand and work with the code.
> >
> > Yes processing is a fun little application -  although I suspect for
> > introductory programming,
> > It's not going to make the grade. I use flash and actionscript for
> > introductory programing
> > because of it's verbose and natural ( like english) syntax.
> >
> > Processing is one of many cute little graphic apps that produce narrow
> > visual expressions.
> > Check BDD( http://www.bermuda.ch/bureaudestruct/bddesigner/index.html
> > -authored in Director )
> > out  for producing 1960's swiss graphics. I use these applications to
> > explore the inevitable imposition
> > of style by produced by graphic applications, in an attempt to lure
> > students away from photoshop filter frenzy.
> >
> > cheers
> > Ian Hobbs
>
> In answer to Alan's question, no, I haven't used it yet; I just heard
about
> Processing.org; but I looked at some of the applets people have made with
> it, and they seem promising.
>
> Whether the visual range of Processing is narrow, I don't know either.
> Certainly it's possible. Just because it has a programming language
> associated with it does not, I suppose, guarantee that the range is
> extrordinary. Nor am I sure what it might take to ensure non-'cuteness' in
> the visual programming realm; a programming language may not suffice if
what
> it operates on does not have--what?--it would be interesting and
challenging
> to specify a necessarily provisional, I think, set of notions of what it
> should be able to do, and what it must not do; for instance, if it
> necessitates a certain look, or a relatively small certain range of looks,
> then what? It doesn't cut it and neither does the art produced with it?
This
> seems an absolute judgement that can neglect even looking at the art or
> experiencing the programming, which I've encountered before, and is often
an
> excuse to simply dismiss the work and concept categorically. Yet, while
this
> is true, it's important to grapple with the notion that, as Ian points
out,
> some tools/languages "produce narrow visual expressions." Or narrow audio
> expressions, etc. But the context can be important, not exactly
independent
> of the breadth of the expression of the particular piece, but opening
into,
> relating to the dialogic of the context.
>
> I saw some visuals tonight by DJ Spooky in a club, and they were often
meant
> for the performative club situation, not meant as independent from that
> context, though there were also at least parts of The Spectacle by Debord,
> which are almost foreign to a performative club situation but had a lot
> eyeballs trained on the screen, that's for sure.
>
> I gather Max is now available for both Mac and PC. I saw a couple of Max
> pieces today in a live setting. Looks vedy inerestin and will for sure be
> checking it out. I gather that it is 'always playing', ie, you can compose
> continually while the piece is playing, as it is being processed. Such
> engines could be constructed in programs like Director, though probably
> things like the 1000-simultaneously-instantiated-sprite-absolute-limit of
> Director, or its lack of real support for dynamic sprite
> creation/destruction would limit a Director-implemented Max-like engine to
> being a kind of prototype. What this means is that Director has a
different
> functional range than does Max. And it is for this sort of reason that a
> 'spec' concerning what it might take for a tool/language to 'make it'
> regarding visual (or other types) of range would have to be provisional:
no
> tool lets you develop *anything you want at all* but is subtlely
> circumscribed in its range by the finite nature of the vision of what it
is
> meant to support (without having to move heaven and earth to get there).
You
> could say assembly language is pretty good in its range, but yeesh, sure,
> you write it for ten years.
>
> ja
>
>
> _______________________________________________
> empyre forum
> empyre@lists.cofa.unsw.edu.au
> http://www.subtle.net/empyre





This archive was generated by a fusion of Pipermail 0.09 (Mailman edition) and MHonArc 2.6.8.