A few thoughts on media, categorisation and criticism

This post on Tom Moody’s blog (found via Rhizome, drawing a distinction between “New Media Artists” and “Artists with Computers” struck me as interesting, especially as it echoes a distinction made in Stephen Wilson’s Information Arts which I am currently working my way through. Moody defines the distinction like this:

New media suggests a respect for hardware & software and belief in their newness, something artists with computers don’t care about. New media involves a finicky devotion to programming and process, whereas artists with computers are bulls in the Apple Shop. New media artists tend to germinate in design or media arts programs whereas artists with computers incline to studio arts backgrounds or autodidacticism.”

By comparison, Wilson outlines four main ways in which [technological / scientific] research functions in various artists works:

  • Exploration of new possibilities
  • Explorations of the cultural implications of a new line of research
  • Use of the new unique capabilities to explore themes not directly related to the research
  • Incidental use of the technology

These four categories of work broadly follow a scale from work whose purpose is to examine the nature of the medium in which it was made, to work in which the medium is incidental to the ‘meaning’ of the work, mapping nicely to Moody’s “New Media Artists” and “Artists with Computers” respectively.

Moody also draws a comparison between “Art Photography” and “Artists with Cameras” that struck me as interesting, particularly when compared with this quote from Wilson:

It is a challenge to work with a medium before anyone defines it as a medium. Yet several years later, when the technology has matured and a body of artistic work and commentary has appeared, the choice does not have the same meaning. At the early stages of an emerging technology, the power of artistic work derives in part from the cultural act of claiming it for creative production and cultural commentary.

Given that we can look at the evolution of a critical framework to talk about photography as art right from The Work of Art in the Age of Mechanical Reproduction” (and probably before) up to the present day at which point there’s nothing particularly novel about art that makes use of photography as a medium (leaving aside Moody’s distinctions for a minute), it struck me that perhaps the distinction between incidental use of a ‘new’ medium and the recursive self-examination of the medium itself that defines Moody’s “New Media Art” is perhaps more to do with differing critical strategies than some sort of innate property of the work itself (Indeed, the assertion that a work itself can have these sorts of innate and canonical properties is problematic to my mind, and probably deserves it’s own post, but to be honest, there’s been plenty written about that already.)

Therefore I was thinking vaguely about there being a sort of hegemonic ’set of all media acceptable to the artworld’, which new media (not necessarily big-N big-M New Media) are absorbed into by a sort of dialectic in which a new medium is utilised specifically as a challenge to this hegemony (as Wilson describes), and is therefore ‘claimed’ as a medium for an art, and consequently absorbed into the hegemonic ’set of acceptable media’, and how Moody’s two distinct categories are really just critical attitudes that tend to be prevalent at the beginning and end of this process of absorbtion, respectively. This is probably a little vague, but struck me as an interesting idea - I’d be really keen to know if there’s any literature about concerned specifically with critical and theoretical attitudes to different media. Anyone in particular I should be looking up?

A handy little trick for method delegation in ruby.

Delegate methods to some other object in a nice declarative way!

Simply extend the class Class, like so:

class Class
  def delegate(hash)
    hash.each do |methods, variable|
      methods = [methods] unless methods.is_a?(Array)
      methods.each do |method|
        class_eval <<-EOS
          def #{method}(*a, &b)
            #{variable}.#{method}(*a, &b)
          end
EOS
      end
    end
  end
end

The semantics of the arguments doesn’t really follow what you’d expect of a hash - this is deliberate, so that the ‘=>’ operator can be read as ‘to’ - eg. delegate :some_method => :@some_object . If this is highly offensive to you, simply switch the argument order, then you’ll have a hash of :objects => :methods_they_recieve, which probably makes more sense.

A trivial example:


class FryingPan

  delegate [:burned?, :description] => :@foodstuff

  def initialize(klass)
    @foodstuff = klass.new
  end

  def cook
    cooking_time = 0
    while !burned?(cooking_time)
      puts description {|name| "I am an #{name}, cooking"}
      cooking_time += 1
      puts "Cooked for #{cooking_time}"
    end
    puts "Idiot! you burned your dinner."
  end
end

class Egg
  def burned?(time)
    time >= 5
  end

  def description
    yield(self.class.name)
  end
end

f = FryingPan.new(Egg)
f.cook

should result in:


>> f.cook
I am a Egg, cooking
Cooked for 1
I am a Egg, cooking
Cooked for 2
I am a Egg, cooking
Cooked for 3
I am a Egg, cooking
Cooked for 4
I am a Egg, cooking
Cooked for 5
Idiot! you burned your dinner.

Something like this may already exist in the ruby standard lib, or in gems - but it was a valuable half an hour exercise, and clarified a lot of the confusion i have about class_eval, and a nice little idiom to use in code.

Braindump of a project idea - RACE.

RACE - Ruby for Arts Computing Education

Why Ruby?
Ruby is awesome. It can be used as a procedural scripting language, with very little conceptual overhead for beginners. However, the fact that it combines Object Orientated (in a really intuitive way - ‘everything is an object’) and Functional programming styles means that students can learn about and explore other programming paradigms as they progress without the conceptual overhead of learning another language. It’s syntactically pretty permissive, (lines aren’t terminated with semicolons, braces and do/end can be used interchangeably, parentheses on method calls are optional), leading to less debugging frustration for the beginning student (and which neednt preclude encouraging a consistent programming style). Ruby has an active, friendly community and loads of libraries that students can use in their projects once they’re familiar with the syntax. It’s also a ‘proper’ language - students can go on to use ruby for real world development, on web applications, desktop apps, or anything else, really, rather than learning another language, unlike Processing or similar ‘arts computing’ environments.
Python’s also great for most of these things, but significant whitespace is confusing and tricky to debug for beginners, and, I’ve never learnt it, so this project wouldn’t get started as quickly.

What we need?
In order to get students to engage with computing, we need to be able to show how they can come up with tangible results that are relevant to their exisitng artistic and educational practice quickly. Therefore, some sort of lightweight framework for arts-based computing in ruby is needed. Initially, we will concentrate on visual art, producing complementary frameworks for music and physical interaction later.

These frameworks should:

1) Be immediate. A beginning programmer with an interest in computer graphics shouldn’t have to worry about instantiating an OpenGL canvas object or any associated gubbins, they should be able to sit down, fire up their learning / programming environment and get to work.

2) Be small, and as transparent as possible. We’re teaching Ruby, not RACE itself. Therefore, the RACE environment should only provide helpers and ‘magic’ where absolutely necessary to facilitate (1). This means no DSLs! it’s difficult for a beginning programmer to differentiate between features of the language and properties of the DSL, if they underrstand the difference between the two at all.

3) Be extendable. Students should be able to leverage all the power of the ruby standard lib and the library code available if they so choose. This is probably a sub point of (2) to be honest.

4) Integrate with students existing workflow. It should be possible to export the results of a student’s use of RACE in a standard format that can be printed, shared, edited in their favorite software packages, or whatever. THey should also (perhaps not immediately) be able to import existing work and manipulate it programatically.

So, what are we going to do?

Initally, build a simple graphics programming environment in ruby, that takes into account the above points. Initially, this might take the form of a rough ruby port of Processing (perhaps incorporating ideas from Logo too), built on top of an existing library for handling the donkey work of rendering images. Later, add to this by building envirronments for music, animation and interfacing with electronics (perhaps using arduino hardware) which can be used seperately or in combination with each other. Produce documentation, example project briefs and lesson plans that use RACE, and advice for incorporating it into existing syllabii for various age groups.

links for 2008-04-07

testing again

yadda yadda. ignore.

testing

don’t mind me

links for 2007-11-27

links for 2007-11-13

links for 2007-11-12

links for 2007-11-10