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(
> -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; 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.


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