Phys Comm Observation Project

For our observation assignment, EJ & I found a T-shaped intersection at Broadway and Bond street at 11:30 on a Monday morning.  We wanted to see how people interacted with a ubiquitous urban technology--the street light.

The street light cycle followed this rough pattern:

Walking Man: 17 seconds (It's safe to cross the street)
Blinking Hand: 10 seconds (Take caution when crossing)
Red Hand: 1 minute (Do not cross)


During any given cycle, we would observe up to 7 people crossing Broadway, with the majority of them crossing during the Blinking or Red Hand stages. Crossing Bond, where pedestrians competed with less traffic, we saw up to 15 people cross during a given cycle.

Here's how the system is designed to work:
Pedestrian approaches intersection, looks up to read the signal, and if the white walking man is illuminated, cross the street. Otherwise he waits through the cycle until it is safe to cross.

Here's how it actually works:
Pedestrian approaches intersection. About forty percent look to the signal to see where they are in the cycle, but most look immediately to oncoming traffic to judge whether it's safe or not. Everyone looks at traffic at some point, either not trusting or not caring what the signal tells them to do.

Waiting patiently to cross.

GO!

Inevitably, some pedestrians misjudge the speed of oncoming traffic and put themselves in precarious situations. This was especially true when pedestrians were interacting with some other technology at the same time--cell phones, iPods, etc--and didn't pay enough attention to the signal or traffic.


The only person we witnessed actually obeying the signal was a woman with stroller. She waited patiently until it was both safe to cross and legal to cross before stepping into the street.


The information that the signal gives pedestrians is related to the red-yellow-green signals given to oncoming traffic. It doesn't take into consideration that automobile traffic routinely ignores those signals. When the system breaks down for people in cars, it breaks down for people on foot.

And since at this intersection drivers routinely ignore the signals, pedestrians have to gather their own information. They're becoming the sensor that the traffic light is missing. If the traffic light sensed the speed and presence of oncoming traffic and relayed that information into a walk/don't walk sign, the technology would work much better.

A response to Olafur Eliasson's Waterfalls

The ideal way to view them must be by driving past, at high speed, along the BQE, perhaps not in the standstill traffic or rush hour, but during the rocketing insanity that comes just before and after. If you're concentrating on avoiding collisions then maybe the waterfalls will only gnaw at the corner of your eye. Let them sneak up on you, and perhaps they'll retain some mystery, the wonder that comes from discovering something completely out of place.

Often, patient contemplation opens art up further, deepens the ideas, sharpens the questions it asks, takes the work and makes it grander. In this case, though, it invites boredom. The waterfalls are diminished by what surrounds them, and their physical structures are too much of the place. Perhaps Walter Ong would point to the power of the naming in his response--call a project New York Waterfalls and you'll invite heightened expectations. Provide cages that spit water and you'll have trouble meeting those expectations. People love waterfalls. They instill in us a sense of awe. But they do so because of their grandeur and beauty and power. When you visit a waterfall, it is the biggest, most dynamic thing in your field of vision and of sound. That's just not the case here, and it really hurts the work.


Look at that waterfall!


In an interview on the Waterfalls offical website, Elliason claimed that the project is more about community then it is about nature. But I'm not sure what a public art projec that can only be experienced from a distance, and which invites little interaction, actually says about community.

Here are two photographs I took in Medellin, Colombia, last April. This first is of a Botero sculpture called "El Pajaro" which was destroyed in 1995 in a bombing that killed 23 people and injured 200.



The next is its replacement, El Pajaro de la Paz, which sits right next to the mangled shell of its predecessor.


It's a sculpture of a bird, but I would put forward that this project is more about community then it is about nature.


Finally, here are two photographs I took yesterday, during the Circle Line boat tour of the Waterfalls.

These are my fellow boat passengers taking in Waterfall #1:




And here they are completely ignoring Waterfall #3:




That sums up their response. And, I guess it sums up mine as well.

A response to Walter Ong's Orality & Literature

So who will we be when we're post-literate? The question seems a wee ridiculous: Once you're literate you can't go back to that old warm orality. But writing is technology, and technologies advance. Ong tell us quite convincingly that "more than any other single invention, writing has transformed consciousness," but he says it with an air of finality. As if writing will enjoy its place of cultural and cognitive primacy forever.

But what if that's not true? If writing and literacy have permanently changed us by giving us a repository for knowledge--a place to store the information that is most pressing to remember, and by doing so, freed us to think in abstractions, then what happens when new technologies allow us that same freedom but with fewer, or different, restrictions? We'll never be rid of text, because almost all recorded thought has been preserved in that form. But until recently it was the only convenient option. While that's still the case, we're getting closer to a point where memories and ideas will be just as easy to store in video or audio other electronic forms, and almost certainly easier to disseminate and share. Photographs have left the page. Words have as well. And one could argue that the breadth of human knowledge is shrinking, at least on certain of its edges--the availability of so much information online makes the stuff that's still moldering in distant archives that much more inaccessible. What good is it if it's written down where we can't find it? Like all those words spoken and then lost before we literacy gave us a way to trap them, ideas that are forgotten cease to exist. In thirty or fifty or a hundred years we'll have exponentially more information to sort through, much more of it in visual, non-textual form then ever before. That's the stuff that we'll be "reading." It's not just the content that is changing, but the way in which we read. Ong praises McLuhan for recognizing the "importance of the shift from orality through literacy and print to electronic media" but he does not expound on what exactly that importance is. Ong explores in fascinating terms the ways in which our understanding of the world is effected when we begin to organize our thinking through writing and print, which are predominantly linear and static forms of storing information. But what happens when we switch from a body of knowledge that is etched in stone or scratched out on paper, to one that is far more fluid? Texts move, as Ong reminds us, "variously from right to left or left ro right, or top to bottom, or all these ways... Texts assimilate utterance to the human body." But what happens now that we communicate in other dimensions, be it by layering meaning in new ways using Internet technologies or using the now-ubiquitous time and space-shifting tools of video and other visualizations? Ong shows us how the alphabet defined sound spacialy, but he doesn't allow for changing realities. Virtual worlds are redefining space. As our language moves both backwards--to an arguably more pictographic lexicon--and forward--to a communication through electronic media--how will it change the way we live in and understand our world?

...


Ong argues that one major way that writing changed us was by introducing what he calls "autonomous discourse," the ability to receive information without being in the presence of the speaker. Literacy allows us to receive information quietly and in seclusion, and also to speak things without fear of being challenged. Reversing this trend would necessitate a return to pure orality. But while the physical separation from ideas at the moment of communication will not be bridged by space, it will be more frequently bridged by time. Ong tells us text has a vatic quality. He writes that "like the oracle or the prophet, the book relays an utterance from a source, the one who really 'said' or wrote the book. The author might be challenged if only he or she could be reached, but the author cannot be reached in any book. There is no way directly to refute a text." This is, of course, no longer true. Witness the mash-up; or tools that allow visitors to append information to any website, accessible by any visitor; or simply the way words can now be linked in a virtual space. Any web search of Orality and Literacy will eventually bring the curious reader to this response and those of my fellow students. That they don't show up on the first page of search results--at least not yet--does not diminish their immediacy. What's important is that they will show up. And that though Ong has passed away, we can respond to his words immediately upon reading them, and any who choose to respond to us can do so, too, and more importantly, can do so in the same space. Texts might remain "inherently contumacious,"* but perhaps no longer with impunity.

*Look it up, lazybones. I had to, too.

Help Make Mr. Piggy Smile

Here's my first bid of code in Processing, written for ICM. I'm having trouble with curves and arcs, so Mister Piggy is a pretty serious dude for now. Someday he will smile.

the pig: http://itp.nyu.edu/~jj891/ICM/week1/index.html

the code:
size(200,200);
background(0,0,255);
smooth();
rectMode(CENTER);
//piggy head
stroke(0);
fill(245,80,120);
ellipse(100,85,150,125);
//piggy nose
stroke(0);
fill(255,100,100);
ellipse(100,100,40,30);
//piggy nostrils
stroke(0);
fill(0);
ellipse(95,100,10,10);
ellipse(105,100,10,10);
//piggy eyes
stroke(0);
fill(255);
ellipse(70,70,30,20);
ellipse(130,70,30,20);
//piggy pupils
fill(0);
ellipse(70,75,7,7);
ellipse(130,75,7,7);
//piggy bow tie
fill(255,255,0);
stroke(0);
triangle(60,140,95,160,60,180);
triangle(140,140,105,160,140,180);
ellipse(100,160,20,15);
//piggy smile
//someday!

Phys Comp Lab 1

The first lab assignment can be found here.

Basically, I was asked to connect a digital input circuit and digital output circuit to a microcontroller. In this case, the digital input is a switch. The digital output: two LEDs. Closing the switch lights one LED, opening it lights the other. Here's an open switch:



The white wires are the switch. Touching them together gives you this:



Pretty simple. Super fun. The next part of the assignment was to get creative with the actual switch as well as the digital input, with the goal of making a combination lock.

I found two items on the ITP junk shelf that I decided to use as the basis for my switch. First was an LED connected to two pushpins:


The other was this cable, which likely has a name, and can generally be found connecting stuff on your motherboard or something green and circuity:



The wire allowed me to make a switch that was fancy looking, but actually really simple. I created five switches and wired them from the bottom of this white cable (after using a multimeter to make sure each end point did in fact connect somewhere on the opposite end) to the ground on my breadboard. I then soldered a pushpin to a wire and connected that to my power source. When I insert the pin in one end of the white cable, it closes that particular switch. So, in effect I'm using one roving power source for five different switches. This solves the problem of people closing two switches at the same time (the equivalent of pressing two buttons) and also looks cool.




Now I wanted to make a combination. That's all programming. I decided that if you closed switches 1, 4 and 5, in that order, a green light would turn on. After each of the first two correct guesses, a green light would brink to let you know you were on the right path. If you messed up a long the way, a red light would flicker. After a couple of seconds, the sequence would restart so you could try again.

I got super stuck until I copied some code from Zoe Fraade. And then I got super stuck until Craig Kapp helped me figure it out. He sat down next to me and generated most of this code, explaining point by point why the way I'd done things wasn't the most simple way to get from point a to point b. Thanks, Craig. I'll figure this stuff out eventually.

Pin in switch one (the green light flashes briefly).


Pin in switch four (the green light flashes briefly).


Pin in switch five (the green light stays on!).


I also wanted to include a red light if you put the pin in the wrong spot. Here, the red light goes off if you put the pin in the first switch after having put it in the first and fourth. More simply: if you think switch one is the final key instead of switch five:


One problem: I tried to figure out the code to make a red light flash if you put the pin into switch two or three at any time. But I couldn't figure it out before class. In the code below, nothing at all happens if you put the pin into switch two or three:
Pin in switch one, after being in switch four.


There are a couple of other problems as well. The reset mechanism is pretty untidy, for example. And there's no good way of telling the user how many switches are in the password. (That's not a problem I diagnosed myself; it came from class discussion of other projects).

Anyway, here's my code. I'll try to revisit it when I learn a little more about variables and loops and subroutines and other things that are, right now, totally over my head.

 

// declare variables:
int switchPin1 = 1; // digital input pin for switch 1
int switchPin2 = 2; // digital input pin for switch 1
int switchPin3 = 3; // digital input pin for switch 1
int switchPin4 = 4; // digital input pin for switch 1
int switchPin5 = 5; // digital input pin for switch 1

int greenLEDpin = 8; // digital output pin for an LED
int redLEDpin = 9; // digital output pin for an LED

int switchState1 = 0; // the state of the switch1
int switchState2 = 0;
int switchState3 = 0;
int switchState4 = 0;
int switchState5 = 0;

int myprogress = 0; //this counts the progress you've made in getting the right combo
int switchon = 1; //this is an idea that craig had, which he forgot to explain or incorporate later. ask him later.


int conditionsFilled = 0; //Keeps track of how many conditions so far have been filled

void setup() {
pinMode(switchPin1, INPUT); // set the switch pin to be an input
pinMode(switchPin2, INPUT); // set the switch pin to be an input
pinMode(switchPin3, INPUT); // set the switch pin to be an input
pinMode(switchPin4, INPUT); // set the switch pin to be an input
pinMode(switchPin5, INPUT); // set the switch pin to be an input

pinMode(greenLEDpin, OUTPUT); // set the yellow LED pin to be an output
pinMode(redLEDpin, OUTPUT); // set the red LED pin to be an output
}

void loop() {
// read the switch inputs:

switchState1=digitalRead(switchPin1); //Sets the inputs to variables that won't take so long to type
switchState2=digitalRead(switchPin2);
switchState3=digitalRead(switchPin3);
switchState4=digitalRead(switchPin4);
switchState5=digitalRead(switchPin5);

//beginning mode



// condition 1
if (switchState1 == 1 && myprogress == 0) //if first switch is on, and nothing else has happened...
{
myprogress = 1; //switch myprogress to one
digitalWrite(greenLEDpin, 1); //blink the green light
delay(1000);
digitalWrite(greenLEDpin, 0);
}
else if (switchState1 == 1 && myprogress != 0) //if switch 1 is on but you've already started down the path
{
myprogress = 0;
digitalWrite (redLEDpin, 1);
delay (1000);
digitalWrite (redLEDpin, 0);
}

// condition 2
if (switchState4 == 1 && myprogress == 1)
{
myprogress = 2;
digitalWrite(greenLEDpin, 1);
delay(1000);
digitalWrite(greenLEDpin, 0);
}
else if (switchState4 == 1 && myprogress != 1)
{
myprogress = 0;
digitalWrite (redLEDpin, 1);
delay (1000);
digitalWrite (redLEDpin, 0);
}

// condition 3
if (switchState5 == 1 && myprogress == 2)
{
myprogress = 3;
digitalWrite(greenLEDpin, 1);
delay(1000);
digitalWrite(greenLEDpin, 0);
digitalWrite(redLEDpin, 0);
}
else if (switchState5 == 1 && myprogress != 2)
{
myprogress = 0;
digitalWrite (redLEDpin, 1);
delay (1000);
digitalWrite (redLEDpin, 0);
}
// goal!
if (myprogress == 3)
{
digitalWrite(greenLEDpin, 1);
delay (5000);
digitalWrite(greenLEDpin, 0);
myprogress = 0;
}

// else {
// digitalWrite(redLEDpin, 1);
// delay(100);
//digitalWrite(redLEDpin, 0);
//delay(100);
//digitalWrite(redLEDpin, 1);


// myprogress == 0;


// }


/*
if (switchState2 == 1 || switchState3 == 1)
{
conditionsFilled = 0; //These aren't part of the password, so they're always wrong. Try again, McGyver.

digitalWrite (redLEDpin, 1); //just so they feel really bad about it
delay (200);
digitalWrite (redLEDpin, 0);
delay (200);
digitalWrite (redLEDpin, 1);
delay (200);
digitalWrite (redLEDpin, 0);
delay (200);
digitalWrite (redLEDpin, 1); //so the red light stays on.
}

*/

}