Main | October 2006 »

September 29, 2006

Week 4 - Photo Montage

Our assignment this week was to make a short video "montage" using 12 photographs, in a way that tells a story. Our team's video is called Candy, download it here. Pretty funny and straightforward if I do say so myself.

We did a lot of preparatory brainstorming and discussion at ITP before setting out to take our pictures. Jack introduced us to a candy store along the way, and we changed our plans immediately, ended up shooting all our pictures there.

However, spending time on the brainstorming gave us all a common vocabulary and understanding of the situation, so when we found the candy store, it was pretty easy to improvise and do something coherent.

September 26, 2006

Week 4: more object oriented fun

I've extended the behavior of the bouncing smileys so that they alternately love and fear the mouse cursor when you click the mouse.

It's all here: Many Smileys Love and Fear the Mouse

Object oriented programming does make this all rather easy. It was pretty straightforward to extend the program without messing up anything else.

September 25, 2006

Observation assignment - Part 1

I made my observations on a route that went from my home, down Astor Pl., Broadway, then up to 25th St. in Chelsea and back home via Second Ave. This is a composite of three consecutive days of observation, mostly to fill in the number of laptop users at Dunkin Donuts on 2nd Ave.

General observations: iPods and mobile phones predominate. Lots of solitary use of devices (ipods, phones laptops). People holding their iPods in hand even when they have bags. Change in device mix from place to place, though this might also be a function of time-of-day. The ratio of iPod to phone is the most variable. Almost all the people I saw with iPods and phones were walking. Laptops only visible in places where connectivity is available, and never used (or visible) while moving.

Keep reading past the link for detailed observations.

10:30, Dunkin Donuts, 2nd Avenue: 2 laptops at Dunkin Donuts (free wireless), users are basically motionless looking at the screen.

10:45, Astor Pl.: 6 headphone wearers and 8 mobile phones, all walking. In general, when phones are in sight, people are talking on them. In about 1/3 to 1/4 of the of cases, people with headphones are using an iPod and holding it in their hand, even though they are not interacting with it.

11:00, Fedex/Kinkos, Astor Pl.: Lots of devices in use. 7 people in the computer rental area, typing or drawing with mouse. 1 person very efficiently scanning photographs on the Sony photo station, very carefully laying out the prints on the scanner bed, and starting the scan. Seems to be very confident, not working quickly, but at a good pace with little hesitation. Another person approaches the machine for self-service cards, pokes at it hesitantly, eventually is told by the cashier that it's not working. I use the fax machine to send 3 pages, notice that the only indication of transmission in progress is a flashing green light.

11:20 - 14:00, Going up Broadway towards Chelsea. Lots and lots of mobile phones and iPods (well, headphone wearers with white earbuds). On average, 1 each per minute, with the mix tending more towards more phones as I get closer to Chelsea. All are walking. In two hours spot 2 people wearing Bluetooth headsets. As before, quite a lot of iPod users are carrying it in their hand, without actually interacting with it. Almost invariably these people also have a bag or backpack, but are not putting the iPod in it. One laptop user at table in Union Square. Three DSLR users, in the area around the Flatiron Building. I think they were in a club, or doing some kind of assignment, since they clustered together. Not a lot of talking, but stayed close.

14:00, at Material Connection, W 25th Street: A video camera, 2 large digital cameras. Some kind of photo opportunity or event related to the use of Tupperware in innovative ways. A group of 12 people are positioned for photographs, with lots of giggling and banter, while photographers and video crew move around. I take pictures too. No-one notices. This takes about 10 minutes. After this, the guy holding the video camera goes around the exhibition by himself. Everyone ignores him and and the camera.

14:25, from Chelsea, to 2nd Ave and 10th via Park Ave.: Many, many phones, but not so many iPods. Many older people using phones. Everyone I see using a cellphone is walking.

15:15, Dunkin Donuts at 2nd Ave: 4 laptop users, two are leaning over one computer and discussing something on the screen. Plenty of touching the screen. This is the first time during the day that I have seen more than one person interacting with a single device at the same time.

15:30, Bank of America, B'way: Several people using ATM inside this small branch. People go in, push some buttons, receive money and walk away, quickly. However, the door gives some problems. You have to put in a card for the door to open. In almost every case, person puts in card, tries door, reinserts card, tries door, until someone inside opens the door for them. (On later inspection, the guide picture showing how to insert the card appears to be useless: the card needs to be inserted upside-down and facing away from the person, for the door to open.)

15:45, at ITP: lots of laptops, not so many mobile phones or iPods. Mostly when people are using laptops they are not talking to each other. However, there are occasional laughs or emotional reactions.

19:30, Dunkin Donuts at 2nd Ave: 6 laptop users, two are sharing a table and talking to each other.

Sensor tester

I made a very simple circuit + program, basically a general purpose sensor testor. What it is made of:

a) 6 LEDs organized like a scale, connected to digital-out pins on the Arduino
b) a toggle switch for calibration mode, connected to digital-in
c) a sensor, connected to analog-in

What it does:

1) If the toggle switch is closed, then the program watches the sensor and records the minimum and maximum values.

2) If the toggle switch is open, then the program reads the sensor and uses the value to light a scale of 6 LEDs.

3) If the sensor has not been calibrated, then when the switch is open all the LEDs are flashed, as a warning.

I wanted to make a general purpose circuit that allows me to not worry about specific sensor values, and instead work with a min & max that are read from the sensor.

This turned out to be unexpectedly useful - I had been using a voltage regulator (unnecessary with Arduino) so all my voltages were only reaching 2.3v, not 5v. However, the calibration made this irrelevant.

I spent a bit of time wiring up two variable resistors with nice dial-like controls, that came out of an answering machine. One had range in the magnitude of 10K ohms, the other 1K ohms. I think they were meant to work together, one to set a gross value and the other to fine tune, with the resistances simply added together. In any case, I fit the appropriate resistors, now both of them return comparable ranges which are easy to scale in software.

Keep reading to see the source code for the sensor tester. Something's not quite right with the scale function - see if you can find it.

// Simple program to read a variable pot, and use it to control a scale of LEDs
// Physical Computing
// Gian Pablo Villamil
// September 24, 2006
//
// Program has a calibration mode when switch is closed - watches for min & max values
// When working, uses sensor reading to light up a scale of LEDs

// define the output LED start and end pins

#define startLEDPin 2
#define endLEDPin 7

// define calibration switch pin

#define calibrationPin 8

// define potentiometer input pin

#define potPin 0

// define output scale
// kludgy but works

#define outScaleMin 7
#define outScaleMax 0

// define interval for blinking

#define blinkTime 500

// variables

int potMin ; // calibrated minimum
int potMax ; // calibrated maximum
int potValue ; // pot value as read
int scaledPotValue ; // pot value as scaled
char calibrated = 0 ; // flag for calibration

int scale(int inputValue, int inputMin, int inputMax, int outputMin, int outputMax);

void calibrate () ;
void warning () ;
void echoReading () ;

void setup() {
// initialize serial communications at 9600 bps:
Serial.begin(9600);
Serial.println("Initialize input pin");
pinMode(calibrationPin, INPUT);
Serial.println("Initialize output pins");
for (int i=startLEDPin; i<= endLEDPin; i++) {
pinMode(i, OUTPUT);
}
Serial.println("Begin reading");
potMax = 0 ;
potMin = 1023 ;
calibrated = 0 ;

}

void loop() {
if (digitalRead(calibrationPin)) {
calibrate() ;
}
else
{
if (calibrated) {
echoReading();
}
else {
warning ();
}
}
}

int scale(int inputValue, int inputMin, int inputMax, int outputMin, int outputMax) {
return ((outputMax-outputMin)*(inputValue-inputMin)/(inputMax-inputMin)+outputMin);
}

void calibrate() {
Serial.println("Begin calibration");
Serial.println("Turn pot to maximum and minimum value");
potMax = 0 ;
potMin = 1023 ;
calibrated = 0;
while (digitalRead(calibrationPin)){
potValue = analogRead(potPin);
if (potValue > potMax) {
potMax = potValue;
};
if (potValue < potMin) {
potMin = potValue;
};
}
if (potMax > potMin) {
calibrated = 1;
Serial.print("Max = ");
Serial.print(potMax);
Serial.print(" Min =");
Serial.println(potMin);
}
else {
Serial.println("Not calibrated!");
}
}

void warning () {
if (millis() % blinkTime > (blinkTime / 2)) {
for (int i = startLEDPin; i<= endLEDPin; i++) {
digitalWrite(i,HIGH);
}
}
else {
for (int i = startLEDPin; i<= endLEDPin; i++) {
digitalWrite(i,LOW);
}
}
}

void echoReading () {
potValue = analogRead(potPin); // read the pot value
scaledPotValue = scale(potValue, potMin, potMax, outScaleMin, outScaleMax);
// Serial.print("Read = ");
// Serial.print(potValue); // print the pot value back to the debugger pane
// Serial.print(" Scaled = ");
// Serial.println(scaledPotValue);
delay(10); // wait 10 milliseconds before the next loop
for (int i= startLEDPin; i<=endLEDPin; i++) {
if (scaledPotValue >= i) {
digitalWrite(i,HIGH);
}
else {
digitalWrite(i,LOW);
}
}
}

September 20, 2006

Week 3: Fun with Object Oriented Programming

Adapted my homework from Week 2 (bouncing smileys) to use object structures.

Note how the faces grow and shrink, as well as move and change color.

I have to say, object programming makes things a *lot* simpler.

Look at it here: Many Object Smileys

(Note: Some people may argue that it should be "Smilies" and not "Smileys". However, "Smiley" is in effect a proper name, and thus the plural is "Smileys". See Wikipedia entry.)

September 18, 2006

Simple Simon v2

I went ahead and made Simple Simon v2. It now has fully debounced input, it echoes user input, and blinks while waiting.

Still haven't gotten around to the harder/easier routine, and the fancy win.

Read more for the complete source code...

// Simple Simon game for Physical Computing
// Version 2.0
//
// Gian Pablo Villamil (gian.pablo@gmail.com)
// September 18, 2006
//
// Changes from V1.0
//
// No use of constants in for loop (done)
// Debugged GetAnswer (debounce) (done)
// Blink while idle (done)
// Echo input (done)
// Fancy win routine
//
// Arduino blinks LEDs in a randomly chosen sequence. Player must press
// matching switches in same sequence.
//
// If correct, green LED lights and game is made harder (shorter delay, longer sequence)
// If wrong, red LED lights and game is made easier (longer delay)
//
// Required parts
// Game sequence - red, green, blue, yellow LEDs
// Scoring - red, green LED
// Input - four momentary switches

// Define the pin assignments for the output LEDs

#define GameLEDStartPin 2
#define GameLEDEndPin 5
#define LoseLEDPin 6
#define WinLEDPin 7

#define DebounceTime 10 // debounce time in milliseconds
#define BlinkTime 250 // blink time during input

// Define the pin assignments for the answer switches

#define AnsSwitchStartPin 8
#define AnsSwitchEndPin 11

// Define the arrays to hold the "challenge" sequence and
// the user response.
//
// In the GameArray and AnswerArray, the values are:
// 0 = yellow
// 1 = blue
// 2 = green
// 3 = red

int maxGameLength = 10;
int GameValues = GameLEDEndPin - GameLEDStartPin ;
int GameArray[10];
int AnswerArray[10];

// Define starting game state

int curGameLength = 4; // four blinks
int curGameDelay = 1000; // 1 second

// Define turn score and total score

int turnScore = 0 ;
int totalScore = 0 ;
int rightAnswer ;

// counter for debouncing routine

long SwitchDownTime ;

void setup () {

pinMode(LoseLEDPin, OUTPUT);
pinMode(WinLEDPin, OUTPUT);

for (int i = GameLEDStartPin; i <= GameLEDEndPin; i++) {
pinMode(i, OUTPUT);
}

for (int i = AnsSwitchStartPin; i <= AnsSwitchEndPin; i++) {
pinMode(i, INPUT);
}

}

// Main loop - should be easy to follow

void loop () {
randomizeGame () ;
showGame () ;
getAnswer () ;
checkAnswer () ;
if (rightAnswer) {
Success();
MakeHarder();
}
else
{
Failure();
MakeEasier();
}

}

// Fill the game array with random values between 0 and 3

void randomizeGame () {
for (int i = 1; i <= curGameLength; i++) {
GameArray[i] = random(0,GameValues+1); // what's up with this? 0 to 3 returns max of 2
}
}

// Blink the LEDs according to the values in the game array

void showGame () {
for (int i = 1; i <= curGameLength; i++) {
digitalWrite(GameArray[i]+GameLEDStartPin, HIGH);
delay(curGameDelay); // long pause to show game
digitalWrite(GameArray[i]+GameLEDStartPin, LOW);
delay(curGameDelay/2); // short pause to ensure separation is clear
}

}

// Get the user's answer and store it in the answer array
// Must check debounce routine

void getAnswer () {
int finishedAnswer = false ;
for (int i = 1; i <= curGameLength; i++) {
finishedAnswer = false;
while (!finishedAnswer ) {
for (int j = 0; j <= GameValues; j++) { // poll the switches
InputBlink();
if (digitalRead(AnsSwitchStartPin+j)) {
SwitchDownTime = millis() ;
digitalWrite(GameLEDStartPin+j, HIGH);
while (digitalRead(AnsSwitchStartPin+j)) {InputBlink();} // wait for switch to be released
digitalWrite(GameLEDStartPin+j, LOW);
AnswerArray[i] = j;
if (millis() - SwitchDownTime > DebounceTime) { // time out will go here
finishedAnswer = true;
} // end if
} // end if
} // for
} // end while
} // end for
} // end GetAnswer

// Compare each element of the game and answer arrays
// If they match, increase the turn score
// If the turnscore equals length of the game, then it's right

void checkAnswer () {
turnScore = 0;
rightAnswer = false;
for (int i = 1; i<= curGameLength; i++) {
if (GameArray[i] == AnswerArray[i]) {
turnScore = turnScore + 1;
}
}
if (turnScore == curGameLength) {rightAnswer = true;}
}

// Reward the user - flash the green LED

void Success () {
digitalWrite(LoseLEDPin, LOW);
digitalWrite(WinLEDPin, HIGH);
delay(1000);
digitalWrite(WinLEDPin, LOW);
totalScore = totalScore + 1;
}

// Punish the user - flash the red LED

void Failure () {
digitalWrite(WinLEDPin, LOW);
digitalWrite(LoseLEDPin, HIGH);
delay(1000);
digitalWrite(LoseLEDPin, LOW);
}

// Make the game harder - reduce delay and/or increase length

void MakeHarder () {
}

// Make the game easier - increase delay and/or decrease length
// Maybe make it smart by looking at turnscore/gamelength

void MakeEasier () {
}

//
//
void InputBlink() {
if (millis() % BlinkTime > (BlinkTime / 2)) {
digitalWrite(WinLEDPin, LOW);
digitalWrite(LoseLEDPin, HIGH);
}
else {
digitalWrite(LoseLEDPin, LOW);
digitalWrite(WinLEDPin, HIGH);
}

}

Week 2 assignment: Many Smileys

Week 2 ICM assignment is here: Many Smileys

Uses iteration using for loops, also arrays and function calls.

Had a couple of stumbles: array declaration is different from Arduino, and function return syntax is very different from Pascal

September 17, 2006

Next steps for Simon game, combination lock

Here's what I'll do next to the Simon game:

  • Polish the code, fix in-line constants, etc...

  • Write a much better input routine that debounces, echos the input, and signals the input state

  • Do the fancy "win" song & dance
My next project is to use the same hardware, but adding an enter button. Then I can build a working combination lock. I can probably re-use the showGame code and the input routine from Simon.

In terms of aesthetics, I might braid the cables from the switch panel, and run them to 4 pin headers, also do the same for the LED cables.

September 15, 2006

My first project - Simple Simon game!

I got this thing to work, and am very pleased!

Pictures are here.

It's basically a Simple Simon game. The LEDs blink in random order, then the player has to press the buttons in the same order. If you get it right, the green light blinks (and in future, the game gets harder). If wrong, the red light blinks (and game gets easier).

The hardware was straightforward - just a bunch of LEDs and a row of switches salvaged from a busted answering machine in the junk pile. (Potential pitfall of stuff from the junk pile - it was thrown away for a reason, maybe stuff won't work.) I wrote a simple program to test the switches by lighting the corresponding LED.

Hardest part was getting to grips with C syntax, which is new to me. My structured programming techniques from 20 years ago worked well. In fact, I think structured programming techniques apply to hardware design as well. I tried to be tidy in order to keep things organized and easy to manage.

It still has a couple of bugs to be worked out - however, I am thinking of leaving it as-is. Why? Because the stories people create to account for the game's malfunction are far more interesting than the reactions when it works correctly. When it works fine, people can play for a bit, see how it works, and then get tired and walk away. They don't need to really engage. Howerver, a sporadic malfunction is a puzzle: the players have to think hard about what might account for a strange behavior, and this is a much richer interaction than simply playing the game.

I still need to:

* implement debouncing code for the switches, which are sometimes giving double responses
* define constants for the number of LEDs and switches - currently hard-coded in two loops
* implement makeHarder and makeEasier routines - I will work with the amount of error and the time taken to respond
* implement a time-out routine when waiting for input
* implement a blink routine when waiting for input
* make a fancier song & dance for success

Keep reading to see the complete source code for the project.

// Simple Simon game for Physical Computing
//
// Gian Pablo Villamil (gian.pablo@gmail.com)
// September 15, 2006
//
// Arduino blinks LEDs in a randomly chosen sequence. Player must press
// matching switches in same sequence.
//
// If correct, green LED lights and game is made harder (shorter delay, longer sequence)
// If wrong, red LED lights and game is made easier (longer delay)
//
// Required parts
// Game sequence - red, green, blue, yellow LEDs
// Scoring - red, green LED
// Input - four momentary switches

// Define the pin assignments for the output LEDs

#define GameLEDStartPin 2
#define GameLEDEndPin 5
#define LoseLEDPin 6
#define WinLEDPin 7

// Define the pin assignments for the answer switches

#define AnsSwitchStartPin 8
#define AnsSwitchEndPin 11

// Define the arrays to hold the "challenge" sequence and
// the user response.
//
// In the GameArray and AnswerArray, the values are:
// 0 = yellow
// 1 = blue
// 2 = green
// 3 = red

int maxGameLength = 10;
int GameArray[10];
int AnswerArray[10];

// Define starting game state

int curGameLength = 4; // four blinks
int curGameDelay = 1000; // 1 second

// Define turn score and total score

int turnScore = 0 ;
int totalScore = 0 ;
int rightAnswer ;

void setup () {

pinMode(LoseLEDPin, OUTPUT);
pinMode(WinLEDPin, OUTPUT);

for (int i = GameLEDStartPin; i <= GameLEDEndPin; i++) {
pinMode(i, OUTPUT);
}

for (int i = AnsSwitchStartPin; i <= AnsSwitchEndPin; i++) {
pinMode(i, INPUT);
}

}

// Main loop - should be easy to follow

void loop () {
randomizeGame () ;
showGame () ;
getAnswer () ;
checkAnswer () ;
if (rightAnswer) {
Success();
MakeHarder();
}
else
{
Failure();
MakeEasier();
}

}

// Fill the game array with random values between 0 and 3

void randomizeGame () {
for (int i = 1; i <= curGameLength; i++) {
GameArray[i] = random(0,4); // what's up with this? 0 to 3 returns max of 2
}
}

// Blink the LEDs according to the values in the game array

void showGame () {
for (int i = 1; i <= curGameLength; i++) {
digitalWrite(GameArray[i]+GameLEDStartPin, HIGH);
delay(curGameDelay); // long pause to show game
digitalWrite(GameArray[i]+GameLEDStartPin, LOW);
delay(curGameDelay/2); // short pause to ensure separation is clear
}

}

// Get the user's answer and store it in the answer array
// Must check debounce routine

void getAnswer () {
int finishedAnswer = false ;
for (int i = 1; i <= curGameLength; i++) {
finishedAnswer = false;
while (!finishedAnswer ) {
for (int j = 0; j <= 3; j++) { // poll the switches
if (digitalRead(AnsSwitchStartPin+j)) {
while (digitalRead(AnsSwitchStartPin+j)) {} // wait for switch to be released
AnswerArray[i] = j;
finishedAnswer = true;
}
}
}
}

}

// Compare each element of the game and answer arrays
// If they match, increase the turn score
// If the turnscore equals length of the game, then it's right

void checkAnswer () {
turnScore = 0;
rightAnswer = false;
for (int i = 1; i<= curGameLength; i++) {
if (GameArray[i] == AnswerArray[i]) {
turnScore = turnScore + 1;
}
}
if (turnScore == curGameLength) {rightAnswer = true;}
}

// Reward the user - flash the green LED

void Success () {
digitalWrite(WinLEDPin, HIGH);
delay(1000);
digitalWrite(WinLEDPin, LOW);
totalScore = totalScore + 1;
}

// Punish the user - flash the red LED

void Failure () {
digitalWrite(LoseLEDPin, HIGH);
delay(1000);
digitalWrite(LoseLEDPin, LOW);
}

// Make the game harder - reduce delay and/or increase length

void MakeHarder () {
}

// Make the game easier - increase delay and/or decrease length
// Maybe make it smart by looking at turnscore/gamelength

void MakeEasier () {
}

September 09, 2006

W1.2 Assignment "Out of Time", "Stations" by Bill Viola

"Out of Time" is an exhibition at the Museum of Modern Art of works dealing with the concept of time. I've chosen to discuss a work by Bill Viola, "Stations", but first will outline how I usually approach this type of work.

In a nutshell, I look for technical accomplishment, innovation (and originality) and a message. This work incorporates all three, and has "depth" - you can keep finding deeper and deeper layers of meaning by continued observation.

"Stations" is installed in a darkened room, and consists of 5 vertically oriented screens playing a monochromatic video. In front of each screen, on the floor, is a polished dark stone slab, positioned in such a way that the video is reflected in it and inverted. The slabs reflect the video, correcting the orientation but placing the figures below the apparent plane of the floor. The five channels of video each represent a nude human figure floating in water, seen from below the waterline and inverted (head down). Every once in a while the video shows the person splashing into the water, accompanied by a loud splash.

Photos of Bill Viola's "Stations" at the MoMa

The level of technical accomplishment is very high - the video is of high quality, shot underwater, carefully lit and processed. The physical installation is of impressive scale (the images are larger than life size) and the placement of the stone slabs is very precise and formal, bringing to mind a mausoleum.

The initial impression is startling: five pale headless human bodies, apparently emerging from a rippling surface and swaying slightly, like some kind of plant. The viewer is allowed to examine a human body in a different way, as a kind of depersonalized yet living thing. On further inspection you realize that one of the figures is a pregnant woman, a common theme in Viola's work, and a clue that he'll be dealing with themes of life, birth and rebirth.

Immersion in water (another common theme for Viola) is also symbolic of birth, so it's pretty obvious that we're dealing with stages of life: birth (splashing into water), growth (pregnancy) and death (the tomblike aspect of the installation). I'm pretty sure examining the human figures more closely would probably reveal yet more meaning, since Viola typically uses people of different ages to represent the passage of time.

The name of the work, "Stations", confirms that we are dealing with stages of life (a human being's passage through time), and also brings to mind the stations of the cross in a Christian church, tying together neatly with the solemn, tomb-like atmosphere of the piece. The nudity of the human figures and their suspension in space is also reminiscent of images of the crucifiction.

I very much enjoyed the work, could spend quite a lot of time experiencing it. The level of technical accomplishment is very high, combining excellent sound & video with a powerful, theatrical setting. The perspective in which the human figures are shown is startling and unexpected (it opens up a new "way of seeing"). Every element of the work is tied together by, and supports, a powerful central theme - the passage of a human being through time.

September 08, 2006

First encounters with electronics

I built my first breadboard circuit today, learned a lot.

First learning, thanks to Roy: when making your power connector, don't bother trying to solder the ends of your lead to the straight headers. It's fiddly and difficult, and you'll end up melting the plastic part of the header. Instead, use pliers to pull out the header pins, and feed through the stripped ends of the wire. Use a blob of glue to secure it. Much tidier.

Second learning: if your multimeter is set to measure AC voltage, and you touch it to a DC circuit, it seems you will kill your LEDs instantly. The instructions on the class note are a bit confusing: if you follow them with the multimeters that are sold at the NYU computer store, they will lead you somewhat astray. Specifically, they suggest moving the red lead, which is actually not necessary. Doing this will set you up to measure AC voltage.

September 07, 2006

Week 1 assignment

First assignment in the Processing environment.

Hello World
Smiley

Comments on reading "As We May Think"

Just re-read "As We May Think", the classic article by Vannevar Bush.

Interesting, as always, and strikingly prescient. He describes the Memex, a kind of desk-sized information retrieval tool, with the ability to make links between materials.

What strikes me, however, is his failure to foresee digital technologies. He comes close: when he describes the camera of the future, he refers to raster-scanning and television. However, when it comes to the Memex, he posits a highly improved form of microfilm, and doesn't consider the possibility of applying raster-scanning (digitalization) to other forms of stored information.

Comments on reading - "Non-Zero"

Read an interesting article called "The Invisible Brain" by Robert Wright, an extract from "Nonzero: The Logic of Human Destiny". By drawing on the example of the Northwestern Amerinds and contrasting them with the Shoshone, and with Amazonian tribes, he argues that it is the density of trading and social exchanges among people that drives wealth.

I find this an interesting thesis, and was struck by the link to transaction economics (a favorite subject of mine). Wright talks about how transport and communications costs hamper the development of trading networks, and how high population densities reduce these. It occurs to me that what he is describing is precisely components of transaction costs, and that he is describing a subcase of transaction economics.

He might be able to extend his argument by including governance costs in his assessment, since it is the relative difference between transaction and governance costs that drives the shape of political and commercial organizations. When transaction costs are very low relative to governance (roughly, administrative) costs, it is more efficient to trade, and to "loosen up" organizational boundaries. For example, being able to cost-effectivley monitor the performance of an outside vendor vs. an internal department, makes outsourcing more attractive. When governance costs are low, but transaction costs are high, then trading is less effective and organizations (and societies) tend to become more closed-in and self-sufficient. For example, in the former Eastern bloc, when transaction costs were prohibitively high (there were no markets), organizations tended to integrate heavily - car factories produced their own sausages, ran their own hospitals, etc.

I'll write more on this later and add further examples.

W1.1 Assignment, "The Language of New Media"

Lev Manovich's "The Language of New Media" attempts to define what is, and what is not, New Media by listing a series of differentiating attributes, and by demolishing some myths.

I feel that Manovich's defining attributes miss a key point: that New Media meeting his criteria are no longer directly perceivable by human senses, but instead require the intervention of the computer. Implicit in this, is that the process of consuming media requires a simultaneous process of reconstruction, that necessarily is subject to manipulation and distortion. This is not so different from current models of the way cognition functions - however, these models are heavily influenced by computer technology.

This said, perhaps one of the roles of an artist working in new media can be to draw attention to this possiblity of ongoing manipulation and distortion, and encourage the viewer (consumer? spectator? partner in interaction?) to reflect on the ways this may occur in older media, and in their own procesess of cognition.

Manovich lists the defining attributes of New Media as 1) Numerical Representation, 2) Modularity, 3) Automation, 4) Variability and 5) Transcoding. He draws out some key implications of these, but in my view misses one of the most significant: that New Media, so defined, cannot be directly perceived by human senses without the intervention of the computer, and that intervention introduces the possibility of invisible manipulation.

Many previous media can be perceived "unassisted": a painting can be viewed simply by observing its canvas, a photograph can be viewed without having the camera on hand, a book can be read without having a printing press available. Cinema is an interesting case, in that a projector is required to view a movie in its proper form, as moving images. However, physical examination of the film will reveal visible still images, and it is possible to extract some meaning this way. Pre-digital audio is also interesting, in that physical examination of the media does not allow actually hearing the contents of the piece (you can't listen to an LP by putting it against your ear).

However, both cinema and pre-digital audio allow for relatively little manipulation - for the most part, what is played back is pretty much what the creator of the work intended. Though Burroughs, Gysin, etc. did play with cinema ("cut-ups") and DJs do manipulate LPs (by scratching), this manipulation is usually very obvious, and an explicity part of the work.

The interesting thing about new digital media is that it is almost impossible to verify the authenticity of a work by examining the digital media directly - the work is created anew, by the computer, every time it is viewed/listened to. A viewer cannot get a sense of the work by looking at a CD, or a hard drive, or an internet connection. A printed representation of the numeric data is not often going to be intelligible. (There are exceptions! I know many coders who can look at a memory dump and infer what is going on, in a process analogous to reading a score.) However, viewer expectations are that it still exhibits characteristics of old media in terms of permanence and repeatability, and these expectations are often inaccurate.

For example, a printed encyclopedia does not vary once it is published. Updates are released in the form of new editions, which must be physically purchased and replaced, in a very obvious stage. Something like the Wikipedia, however, can be transparently updated without a user being aware that changes have occurred. Thus it is possible to "change history" by editing entries after the effect. As the Wikipedia has become more mainstream, this is now becoming an endemic problem! (Example: Mark Taylor Wikipedia Controversy) This is not to say that old media can't be changed: for example, during the Stalin era in the USSR, periodic instructions would be sent to alter encyclopedias and reference texts by cutting or blacking out photographs of political figures that had fallen out of favor. At least this process was highly visible, and left trails!

In another example, previous generations of video recording technology were relatively fixed: if you taped a show using a VCR, and put that tape on a shelf, it would not change. However, recent versions of Tivo allow for a broadcaster to retroactively modify or delete a recording, without the user being aware of this!

Some would argue that new media are actually more similar to the way human consciousness works (at least in current models), with a constant synthesis and recreation of the environment, and with notoriously inaccurate, and variable, memories. I would argue that the permanence of older media is actually a useful counterbalance to the variability of the human mind (eg. in law enforcement, business and law) and that it may be dangerous to lose it. Many online shops and financial institutions still require a signed fax to confirm large transactions. (Note that the immutability of old media is to some extent illusory, hence the popularity of forgery throughout history.)

However, the very mutability and variability of new media does seem to be inspiring further reflection on how the mind works, and the extent to which old media can also be manipulated and distorted. Someone who grows up with a keen awareness of the variability of new media may also develop a healthy skepticism about old media, and even habits of thought.

So what does this imply for an artist working in New Media?

Rather than attempting to recreate old forms using new tools, perhaps a valuable activity might be to draw attention to the possibilities of manipulation and distortion, and encourage viewers (listeners? consumers? participants?) to reflect on how these distortions are present in old media, and even in the way they and others see the world.

September 05, 2006

Welcome to my ITP class blog

This is Gian Pablo's ITP class blog. I'll be using this to post homework assignments and class-related notes. It's organized by categories according to class, with a couple of additional categories.

For non-ITP related stuff, check out my main blog at http://www.villamil.org/