Frontier Nerds: An ITP Blog

It would be great to pick a point in your day to “fork” — to split time into two distinct paths, and consider / test / explore different outcomes. How, for example, would my day be different if I ordered that Falafel spicy instead of regular? My fantasy device would make answering this question easy.

The closest we’ve come so far to building interfaces to time travel are the version control systems used to manage source for big software projects, and the DVR systems common to cable and satellite boxes. So my device — The Time Fork — attempts to make some of these ideas accessible and intuitive. The device assumes that the basic mechanics of time travel, multiple universes, quantum mechanics, etc. are all sorted out.

To keep things simple (accumulation of features is left to subsequent iterations), let’s assume a few things:

1. You can only maintain a maximum of two time channels simultaneously — e.g. when you fork at, say, 10:00 AM, you’re left with the current instance of existence, call it Channel A, and one new one, which also starts at 10:00 AM, called Channel B.

2. Time only moves forward in the currently active Channel. If you spend 5 minutes in Channel A, then after 5 minutes of real time, the time code for Channel A would advance 5 minutes, while Channel B would remain stuck in the past.

3. Forking overwrites and the other time channel. For example, if you fork Channel B at 10:05 AM,

To keep these issues and the irritating paradoxes of time travel as subtle as possible, my design is built around the most familiar of time-management objects: the wrist watch.

The setup is as follows: It looks like a relatively generic wrist watch, but there’s an extra set of hands on the face. The hands are color coded to represent which of the two possible time channels they represent.

Then there are two buttons, “Fork” and “Switch”.

“Switch” toggles the wearer between the two parallel universes. For example, if it’s 10:15 AM in Time Channel A, and 11:00 AM in Time Channel B, hitting the switch button will move the wearer from one channel to the other.

“Fork” overwrites the inactive channel with a new version of the present. For example, if you’re at 10:15 AM in Time Channel A, then pressing fork will set Tim eChannel B to 10:15 AM.

Instead of a push-button, switch might be better served with a rocker or toggle switch, so that it would be immediately evident which of the two channels you’re currently existing in.

This week’s lab came together without incident. The LED’s change in brightness was far from linear, though. The full range of adjustability was probably covered in the first quarter-turn of the potentiometer. Mapping the value sent to Pin 9 (via pulse width modulation) could fix this, but I wonder if it’s a flaw in the circuit or just a property of the LED.

Also, seeing the code for the PicBasic on Tom’s page about analog makes me appreciate how much boilerplate Arduino spares us.

Here’s the video:

Also, an aside: Any reason to favor the byzantine 6-hookup breadboard power configuration (left) over cleaner 4-hookup approach (right)?

Update: Just a style thing. When you’re using a voltage regulator, using six is more convenient.

Some thoughts on Walter Ong’s Orality and Literacy: The Technologizing of the Word The full text is available online to NYU students.

The immediate temptation after reading the first four chapters of Walter Ong’s Orality and Literacy is to reconsider and recast his claims in the context of the web.

There are many ways in which communication on the internet resembles a continuation of the arc of high literacy Ong outlines: Blogs perpetuate the written diary’s solipsism. Email and SMS nudge away holdouts of secondary orality like phone calls and voice mail. The trend towards concision — the 140 character obsession, for example — has dispatched with the “formulary baggage” and “copia” associated with orality.

These newfound parallels to (and efficiencies over) pre-web literacy are inevitable enough. But even as our dependence on the written word intensifies, the web also seems to shift the spirit and style of communication back towards Ong’s definitions of orality. Yes, the bulk of our interface with the web consists of lines and lines of text, and yes, it’s missing so many of the existential elements that characterize a physical conversation — nevertheless, the tone of the web is often better aligned with traditions of orality than literacy. As such, the web disrupts Ong’s narrative of orality’s decline and literacy’s ascent.

Flickr, YouTube, and similar platforms offer obvious counterpoints to the web’s textual fixation — but the comment text annotating the imagery on these sites, and the general state of discourse on the web, offers more evidence of a return (relapse?) to orality.

Ong describes the essential challenges of writing: “To make yourself clear without gesture, without facial expression, without intonation, without a real hearer, you have to foresee circumspectly all possible meanings a statement may have for any possible reader in any possible situation, and you have to make your language work so as to come clear all by itself, with no existential context.” he writes. “The need for this exquisite circumspection makes writing the agonizing work it commonly is.”

The web’s glut of emoticons and long strings of emphatic punctuation don’t really solve these challenges — instead, they sidestep writing’s agony by adding some orality to the text. And since every post is predicated on the anticipation of a response, a kind of meter finds its way into the communication — more Iliad and less Finnegan’s Wake.

In chapter 3, Ong lays out a list of characteristics of oral culture … it’s interesting to see how many of these are aligned with the current state of communication on the web. Here are a few that stand out:

Aggregative rather than analytic — a sense of truth emerges on the web through aggregation of common opinion, forming pockets of (local) consensus.

Redundant or ‘copious’ — The need to keep text short may reduce redundancy on the individual level, but part of the aggregation process mentioned above depends on (even assumes) overlap and repetition across individual opinions.

Agonistically toned — The web is rich soil for polemics, hyperbolic insults, and has ample supply of the “your mom” jokes Ong cites as oral tradition.

Empathetic and participatory rather than objectively distanced — Online communication seems to straddle these categories. Distance abounds, as does empathy and participation.

Homeostatic — “Sloughing off memories which no longer have present relevance.” In some senses, the web has an incredible memory — information sticks to it readily, and tends to endure. In direct comparison to oral traditions, the web hardly tends toward homeostasis. Yet, if the web’s currency is attention, then mere existence of information is not the whole story: it’s important to consider where the mice and eyes are pointed, and these tend to move quickly from one focal point to the next. (From meme to meme…)

Doorways, automobiles, and rooftops seem to accumulate sensors. Many were out of order — presence seems more important than functionality in some cases.

A slideshow is available on Flickr.

Blink worked fine, no incantations required. Likewise for the first half of this week’s Digital Input and Output Lab. I used a tiny pushbutton switch that drops straight into the breadboard.

I ended up putting together a crude, digital (literally) combination lock system in response to the “Get Creative” suggestion at the end of the lab. Instead of turning a dial or punching keys, I wanted to make something that you could wave your hand over to interact with — the number of fingers held up during the process, could, in turn, enter the code.

For example, to enter the combination “3, 2, 1” (which is, incidentally, the combination to the prototype) you would first wave three fingers, then two fingers, and finally a single finger over the system’s sensor.

I wired up a light dependent resistor to track when a hand is waved over the system, and to count how many fingers you were holding up. This proved a bit tricky. Here are a few issues dealt with along the way:

In the eye of a photoresistor, what does a hand look like, what does a finger look like, and how to we separate them from background?

I experimented with some averaging and smoothing algorithms, but these proved too fussy. In the process of setting up serial communication back to my computer so I could keep an eye on variables, I added delay(60) to the main loop to prevent the serial situation from getting out of hand. (Update: Turns out this is not necessary.) This had the side-effect of smoothing out the input from the photosensor, while still hanging on to enough resolution to distinguish individual fingers flying overhead.

I set up a threshold value to decide whether the jumpy analog signal coming in from the photoresistor represented a hand. Finding the correct threshold value for different lighting conditions was a problem. Ideally, the threshold should be just below (e.g. darker) the number representing the ambient light hitting the photo sensor. Ambient light levels change, though, and the exact threshold has a big influence on the sensitivity of the system and how accurately it counts fingers. Again, I tried out some averaging algorithms to see if the code could learn about the ambient light levels in a particular room. Execution was problematic, though, so in the interest of time I ended up adding a potentiometer to the circuit so the threshold can be set manually as conditions change.

Here’s a quick video demonstrating entering the “3, 2, 1” code. The red LED is illuminated when the system is “locked” — and a green LED flashes when unlocked. Yellow flashes as fingers are detected.

Update: Here’s the code. Bear with me, I’m still sussing out the best way to embed code in the blog.

// digital lock
// eric mika
// september 2009

// here's the combination!
int lockCombination[] = {3, 2, 1};

// store the user's combo for compairon
int enteredCombination[3];

boolean locked = true;

// analog pins
int photoResistor = 5;
int potentiometer = 4;

// digital pins
int yellowLedPin = 9;
int redLedPin = 11;
int greenLedPin = 13;
int lockSwitch = 5;

// store analog values
int photoValue = 0;
int potValue = 0;

// how much the photoresistor must change before we register a finger
// set by the potentiometer for simplicity's sake
// eventually should find a way to have this adjust intelligently to
// changing light conditions
int threshold = 0;

// keep track of fingers moving over
int fingerCount = 0;
boolean haveFinger = false; // currently have a finger
boolean waitingForNextFinger = false; // still waiting for the next finger
int fingerTimer = 0; // counts up between fingers
int fingerFail = 20; // how long before we give up on the next finger and declare the gesture complete

// how long to wait between attempts
boolean enteringCode = false;

int gestureCount = 0;
int codeTimer = 0;
int codeFail = 50;

void setup() {
  pinMode(yellowLedPin, OUTPUT);
  pinMode(redLedPin, OUTPUT);
  pinMode(greenLedPin, OUTPUT);
  pinMode(lockSwitch, INPUT);

  Serial.begin(9600);
}

void loop() {
  // listen for the lock switch
  if (digitalRead(lockSwitch) == 1) {
  locked = true;
  digitalWrite(redLedPin, HIGH);
  digitalWrite(greenLedPin, LOW);
  enteredCombination[0] = 0;
  enteredCombination[1] = 0;
  enteredCombination[2] = 0;
  fingerCount = 0;
  gestureCount = 0;
  Serial.println("Locked!");
  }

  if (locked) {
  // read from the analog pins
  photoValue = analogRead(photoResistor);
  potValue = analogRead(potentiometer);

      // potentiometer sets the finger threshold
      threshold = potValue;

      // Serial.print("Photo Value: ");
      // Serial.print(photoValue);
      // Serial.print("\tPot Value: ");
      // Serial.println(potValue);

      // flash the yellow when it picks up a finger
      if (photoValue < threshold) {
        digitalWrite(yellowLedPin, HIGH);
        haveFinger = true;
      }
      else {
        digitalWrite(yellowLedPin, LOW);

        // if that's the end of a finger, then start waiting for the next
        if (haveFinger) {
          fingerCount++;
          fingerTimer = 0;
          haveFinger = false;
          waitingForNextFinger = true;
        }
      }

      if (waitingForNextFinger) {
        // bump the timer
        fingerTimer++;

        // shine the green light to show we're grabbing the next one
        digitalWrite(greenLedPin, HIGH);

        if (fingerTimer > fingerFail) {
          // register a gesture
          enteredCombination[gestureCount] = fingerCount;
          gestureCount++;

          Serial.print("fingerCount: ");
          Serial.print(fingerCount);
          Serial.print("\tgestureCount: ");
          Serial.println(gestureCount);

          // check the combination if we're on 3
          if (gestureCount == 3) {
            // does it match?
            // tried to write a function for this process, but compiler choked
            if ((enteredCombination[0] == lockCombination[0]) &&
              (enteredCombination[1] == lockCombination[1]) &&
              (enteredCombination[2] == lockCombination[2])) {

              Serial.println("Opened!");
              locked = false;
            }
            else {
              Serial.println("Wrong combo!");
            }

            // reset it since we're past three
            gestureCount = 0;
          }

          waitingForNextFinger = false;
          fingerCount = 0;
        }
      }
      else {
        digitalWrite(greenLedPin, LOW);
      }

      // seems like a bad thing, but helps smooth the analog input
      // should rewrite the whole timing approach using millis()
      delay(20);

      digitalWrite(redLedPin, HIGH);
  }
  else {
    // it's open!
    digitalWrite(yellowLedPin, LOW);
    digitalWrite(redLedPin, LOW);

    // why not flash the green LED to celebrate
    if (digitalWrite(greenLedPin, HIGH);
    delay(100);
    digitalWrite(greenLedPin, LOW);
    delay(100);
  }
}