print.ln(“Code”);

(Response to “Her Code Got Humans On the Moon – and Invented Software Itself” by Robert McMillan and Casey Reas’s Eyeo Festival 2012 talk)

Having read McMillan’s article and watched Reas’s talk, my first thought is that Casey Reas gave numerous examples of the world at the service of code, and Hamilton’s story is one of code at the service of the world. These are generalizations, of course. But viewed in this way, the world at the service of code produces art and code at the service of the world produces science and engineering.

And guess what. We’re back to the conflict sparked by Roberto Casati a few weeks ago.

Both cases appeal to me in different ways, as I’m sure they did to most of us. Reas shows the many possibilities that code offers in terms of art and creativity, with projects whose purpose is to find meaning, rebel, experiment, and produce an aesthetic experience. For this, he let his projects be influenced by biology, architecture, art history, and the laws of probability among others.

Margaret Hamilton’s involvement with MIT and the NASA, on the other hand, exemplifies the practical, innovative, and revolutionary nature of code and software, which have applications that quite literally allowed humans to navigate outer space in the sixties. As the article itself mentions, Hamilton helped set in motion a way of organization and thinking that is “eating the world.”

Despite their differences, Reas’s and Hamilton’s work share similarities. Firstly, because they use the same tools (code). But also because, as has come to our attention, the “natures” of art and science are closer to each other than is commonly conceived.

An example is the incident experienced during the Apollo 8 mission, when Jim Lovell made a mistake and pressed the wrong command during the flight. Hamilton had anticipated this possibility, but NASA authorities told her that astronauts would never make that error. Oh NASA.

Casey Reas talk about chaos in relation to our humanity, describing it as more natural for us than organization; thus our need to express chaos in art when the advent of the machine seemed to want to prove otherwise. We can’t be “programmed” in a conventional sense: we stray away from rigid patterns and standards. But like Hamilton, we can program in anticipation to deviations, or like Reas, create the deviations with code itself.

Memory

La memoria del corazón elimina los malos recuerdos y magnifica los buenos, y gracias a ese artificio, logramos sobrellevar el pasado.

-Gabriel García Márquez, El amor en los tiempos del cólera

Growing up, this is the image of myself I always had, given that my parents placed this photograph in our living room:

Ever since, this is my notion of my self-portrait, no matter how old I get. Thus, this is the image I wanted to use for this assignment.

I had more free time than usual before this assignment’s deadline (with Spring Break come up soon and all that), so I decided to draw the face line by line (with no fill) on Processing. It took time to do so, but I really like the result. The process was as follows:

I cropped the original self-portrait to obtain just the face (no time to do the entire body, no way José).
I traced the outline of the face and the hat, alongside their features, on the very trusty, very efficient Microsoft Paint.
Based on the previous image, I drew dots on the ends of the straight lines (and at their intersections) that I then used to create lines on Processing.
I obtained each pixel’s position from Paint itself. Paint is great.

My Processing sketch can be found online (it was uploaded following Aaron’s very helpful instructions); it shows not just the self-portait, but also a very simple form of interactivity.

I wanted to add the bright-colored squares to implement what we learned in class about Processing. It made sense to me to reveal the self-portrait in this way; this photograph of me as a child is packed with memories, happy and colorful ones if you will, that I accumulated over the years. I hope the squares translate into that.

I added the text telling the user what they can do, to enable the interaction. I guess the major issue right now is that the browser window will not always be the same size as the canvas, and thus, the instruction that says “Click anywhere” isn’t completely true, for the squares can only exist within the canvas.

This is the code for the sketch:

int i = 0;
//counter that defines hue (for color mode HSB), goes from 0 to 239
int j = 10;
//counter that defines the color squares' width and height, increase gradually as long as the mouse is pressed
int k = 0;
//counter that slows down the creation of new squares, such that the user can "calculate" where they place the squares

void setup(){
 size(550, 550);
 //canvas size, almost equal to that of the photograph that I copied for the self-portrait
 background(255);
 //white background
}

void draw(){
 if(mousePressed){
 if(k%3 == 0){
 // k counter "triggers" the action every three loops
 colorMode(HSB);
 stroke(i, 240, 240);
 fill(i, 240, 240);
 //i = hue value
 rect(mouseX, mouseY, j, j);
 j += 10;
 //upper left corner of square set where the mouse pointer is, square dimensions increase by 10 pixels with every loop
 if(i == 239){
 i = 0;
 }
 else{
 i++;
 };
 //hue value also increases with every loop, by 1 (and restarts at 239)
 k++;
 //k counter increases by 1
 }
 else{
 k++;
 };
 }
 else{
 j = 10;
 };
 //if the mouse isn't pressed, the j counter is restarted such that when the mouse is pressed again, squares begin with the smallest dimensions
 
 noFill();
 
 if(keyPressed){
 stroke(221, 133, 178);
 background(255);
 }
 else{
 stroke(255);
 };
 //if a key is pressed, the background goes back to white and the lines of the self-portrait show colors
 //in this case, the top of the hat is in a shade of pink
 //if a key isn't pressed, the lines of the self-portrait are white
//the rest of the code shows the different sections of the self-portrait, with their respective colors when a key is pressed
 
 //hat top (outline)
 line(247, 36, 295, 48);
 line(295, 48, 347, 50); 
 line(347, 50, 369, 75); 
 line(369, 75, 386, 86);
 line(386, 86, 390, 97);
 line(390, 97, 428, 156);
 line(428, 156, 429, 176);
 line(429, 176, 436, 191);
 line(436, 191, 425, 193); 
 line(425, 193, 411, 193);
 line(411, 193, 401, 193);
 line(401, 193, 390, 194);
 line(390, 194, 319, 167);
 line(319, 167, 215, 167);
 line(215, 167, 186, 176);
 line(186, 176, 149, 178);
 line(149, 178, 135, 180);
 line(135, 180, 118, 190);
 line(118, 190, 116, 182);
 line(116, 182, 129, 137);
 line(129, 137, 161, 92);
 line(161, 92, 194, 70);
 line(194, 70, 206, 59);
 line(206, 59, 217, 48);
 line(217, 48, 247, 36);
 
 //hat top (inside)
 line(206, 59, 185, 89);
 line(185, 89, 200, 88);
 line(135, 180, 151, 155);
 line(148, 179, 184, 163);
 line(184, 163, 191, 154);
 line(148, 172, 169, 154);
 line(201, 166, 201, 152);
 line(142, 148, 170, 108);
 line(159, 142, 178, 109);
 line(178, 109, 182, 105);
 line(182, 105, 192, 98);
 line(192, 98, 216, 96);
 line(216, 96, 231, 88);
 line(231, 88, 292, 60);
 line(199, 135, 209, 119);
 line(206, 109, 219, 107);
 line(219, 107, 246, 110);
 line(200, 144, 254, 126);
 line(254, 126, 332, 132);
 line(332, 132, 350, 146);
 line(350, 146, 382, 150);
 line(382, 150, 362, 137);
 line(362, 137, 353, 123);
 line(218, 155, 297, 155);
 line(297, 155, 339, 163);
 line(299, 143, 331, 141);
 line(331, 141, 354, 164);
 line(336, 97, 365, 113);
 line(355, 90, 371, 98);
 line(371, 98, 358, 75);
 line(358, 75, 349, 78);
 line(425, 193, 421, 170);
 line(411, 193, 387, 164);
 line(401, 193, 385, 177);
 line(408, 170, 398, 155);
 
 //hat bottom
 line(436, 191, 444, 192);
 line(444, 192, 428, 201);
 line(428, 201, 389, 201);
 line(389, 201, 310, 175);
 line(310, 175, 228, 173);
 line(228, 173, 204, 183);
 line(204, 183, 130, 183);
 line(118, 190, 109, 196);
 line(109, 196, 132, 190);
 line(132, 190, 150, 192);
 line(150, 192, 208, 193);
 line(208, 193, 233, 184);
 line(233, 184, 303, 182);
 line(303, 182, 386, 208);
 line(386, 208, 429, 209);
 line(429, 209, 445, 199);
 line(445, 199, 478, 193);
 line(109, 196, 104, 200);
 line(104, 200, 77, 240);
 line(77, 240, 64, 305);
 line(64, 305, 82, 291);
 line(82, 291, 93, 296);
 line(64, 305, 124, 365);
 line(444, 192, 478, 193);
 line(478, 193, 515, 238);
 line(515, 238, 511, 302);
 line(511, 302, 463, 367);
 line(463, 367, 428, 357);
 
 if(keyPressed){
 stroke(106, 50, 48);
 }
 else{
 stroke(255);
 };
 
 //hair
 line(428, 357, 465, 316);
 line(465, 316, 458, 309);
 line(458, 309, 464, 305);
 line(464, 305, 443, 285);
 line(443, 285, 449, 275);
 line(449, 275, 436, 270);
 line(436, 270, 423, 223);
 line(423, 223, 409, 209);
 line(428, 357, 420, 364);
 line(420, 364, 403, 365);
 line(403, 365, 408, 355);
 line(408, 355, 397, 358);
 line(397, 358, 396, 349);
 line(396, 349, 383, 350);
 line(383, 350, 386, 338);
 line(386, 338, 386, 309);
 line(386, 309, 370, 284);
 line(370, 284, 364, 267);
 line(364, 267, 357, 272);
 line(357, 272, 347, 269);
 line(347, 269, 352, 282);
 line(352, 282, 322, 269);
 line(322, 269, 322, 276);
 line(322, 276, 300, 269);
 line(300, 269, 298, 277);
 line(298, 277, 288, 266);
 line(288, 266, 277, 249);
 line(277, 249, 262, 242);
 line(262, 242, 246, 254);
 line(246, 254, 236, 270);
 line(236, 270, 234, 262);
 line(234, 262, 228, 269);
 line(228, 269, 219, 259);
 line(219, 259, 213, 237);
 line(213, 237, 198, 238);
 line(198, 238, 197, 230);
 line(197, 230, 182, 246);
 line(182, 246, 178, 241);
 line(178, 241, 164, 255);
 line(164, 255, 160, 250);
 line(160, 250, 151, 260);
 line(151, 260, 145, 310);
 line(145, 310, 127, 289);
 line(127, 289, 112, 285);
 line(112, 285, 109, 275);
 line(109, 275, 121, 265);
 line(121, 265, 107, 265);
 line(107, 265, 112, 241);
 line(112, 241, 150, 192);
 
 //eyebrow
 line(161, 280, 166, 274);
 line(166, 274, 181, 267);
 line(181, 267, 213, 266);
 line(213, 266, 217, 274);
 line(217, 274, 181, 274);
 line(181, 274, 161, 280);
 
 if(keyPressed){
 stroke(228, 194, 173);
 }
 else{
 stroke(255);
 };
 
 //face (outline)
 line(112, 285, 106, 286);
 line(106, 286, 100, 299);
 line(100, 299, 104, 331);
 line(104, 331, 111, 347);
 line(111, 347, 124, 365);
 line(124, 365, 129, 370);
 line(129, 370, 149, 379);
 line(149, 379, 157, 405);
 line(157, 405, 175, 436);
 line(175, 436, 200, 458);
 line(200, 458, 234, 480);
 line(234, 480, 252, 483);
 line(252, 483, 294, 479);
 line(294, 479, 323, 465);
 line(323, 465, 358, 426);
 line(358, 426, 380, 364);
 line(380, 364, 376, 381);
 line(376, 381, 383, 350);
 
 //ears
 line(380, 364, 391, 367); 
 line(391, 367, 401, 357);
 line(376, 381, 386, 384);
 line(386, 384, 416, 369);
 line(416, 369, 420, 364);
 line(118, 340, 115, 329);
 line(115, 329, 110, 316);
 line(110, 316, 110, 295);
 line(110, 295, 124, 304);
 line(124, 304, 138, 335);
 line(138, 335, 137, 314);
 line(138, 335, 130, 332);
 line(130, 332, 121, 317);
 line(138, 335, 141, 339);
 line(141, 339, 135, 344);
 line(135, 344, 144, 362);
 line(144, 362, 133, 353);
 
 //nose
 line(225, 296, 239, 314);
 line(239, 314, 238, 332);
 line(230, 356, 220, 366);
 line(220, 366, 222, 372);
 line(222, 372, 230, 376);
 line(230, 376, 238, 371);
 line(238, 371, 244, 377);
 line(244, 377, 248, 382);
 line(248, 382, 259, 382);
 line(259, 382, 266, 375);
 line(266, 375, 274, 371);
 line(274, 371, 279, 379);
 line(279, 379, 286, 375);
 line(286, 375, 292, 371);
 line(292, 371, 292, 362);
 line(292, 362, 279, 356);
 line(292, 371, 299, 375);
 line(299, 375, 303, 386);
 line(276, 330, 275, 311);
 line(275, 311, 284, 296);
 
 //wrinkles
 line(167, 329, 194, 336);
 line(194, 336, 215, 331);
 line(215, 331, 227, 323);
 line(212, 354, 232, 336);
 line(292, 328, 311, 334);
 line(311, 334, 331, 334);
 line(331, 334, 343, 331);
 line(203, 387, 194, 398);
 line(208, 426, 223, 448);
 line(238, 455, 281, 455);
 line(281, 455, 298, 439);
 line(305, 395, 314, 399);
 line(314, 399, 317, 406);
 
 if(keyPressed){
 stroke(47, 39, 37);
 }
 else{
 stroke(255);
 };
 
 //eyes
 line(174, 311, 183, 301);
 line(183, 301, 190, 298); 
 line(190, 298, 199, 296);
 line(199, 296, 210, 301);
 line(210, 301, 217, 307);
 line(217, 307, 224, 313);
 line(210, 301, 224, 313);
 line(224, 313, 217, 317);
 line(217, 317, 217, 307);
 line(217, 317, 210, 321);
 line(210, 321, 188, 321);
 line(188, 321, 185, 311);
 line(185, 311, 187, 304);
 line(187, 304, 190, 298);
 line(188, 321, 174, 311);
 
 line(286, 312, 296, 301);
 line(296, 301, 301, 299);
 line(301, 299, 298, 306);
 line(298, 306, 297, 310);
 line(297, 310, 300, 318);
 line(300, 318, 286, 312);
 line(301, 299, 312, 295);
 line(312, 295, 327, 298);
 line(327, 298, 331, 310);
 line(331, 310, 330, 319);
 line(330, 319, 320, 320);
 line(320, 320, 310, 319);
 line(310, 319, 300, 318);
 line(327, 298, 342, 312);
 line(342, 312, 330, 319);
 
 if(keyPressed){
 stroke(146, 61, 63);
 }
 else{
 stroke(255);
 };
 
 //mouth
 line(206, 405, 223, 405);
 line(223, 405, 238, 410);
 line(238, 410, 281, 410);
 line(281, 410, 297, 409);
 line(297, 409, 272, 426);
 line(272, 426, 238, 426);
 line(238, 426, 206, 405);
 line(223, 405, 244, 401);
 line(244, 401, 255, 405);
 line(255, 405, 267, 400);
 line(267, 400, 297, 409);
 line(297, 409, 305, 409); 
 line(305, 409, 274, 440);
 line(274, 440, 254, 443);
 line(254, 443, 235, 440);
 line(235, 440, 206, 405);
 
 textSize(16);
 fill(0);
 if(mousePressed){
 fill(255);
 };
 text("Click anywhere, for as long as you wish", 10, 20);
 //Text at the upper right corner of the page to tell the user to click
 
 textSize(16);
 fill(255);
 text("Press any key to clear screen", 10, 540);
 //Text at the lower left corner of the page to instruct the user how to clear the screen
}

 

Moana: A Story of (Rotary to Linear) Transformation

I watched Walt Disney Animation Studios’ Moana (2016) this weekend. It’s a fantastic movie, very recommended, 10/10.

On an unrelated note (or is it?), I attended Michael Shiloh’s Interactive Media workshop last week, where he taught participants how to create automata and understand the mechanics that they take advantage of. Among his many tips and tricks was the transformation of rotary into linear motion, which professor Shiloh demonstrated with a quickly-made, well-functioning machine of cardboard, hot glue, and wooden sticks. I didn’t get the chance to incorporate this movement into my automaton, but I was eager to use it for this week’s assignment.

There’s a scene in Moana that I found to be one of the movie’s funniest, and it seems that the world’s moviegoers agree. In it, the titular character is teaching a group of young children a traditional dance. An unexpected dancer enters the scene, and hilarity ensues.

Bringing together the concept of automata and Disney’s portrayal of Polynesian dance, I chose to make a dancing Moana for my project. The figure, thus, appears to shake her hips from side to side, imitating Moana’s movements in the film.

The project consists of (1) a circuit and code that connect a hobby motor with an incorporated gear system and a potentiometer, such that the former controls the rotational speed of the latter.

The circuit was built following SparkFun’s example:

Circled in light blue: potentiometer; in pink: motor’s wires; in orange: diode; in green: transistor; in yellow: resistor

The code that controls the circuit is short and straightforward; it simply reads the values given by the potentiometer and uses them as the motor’s output.

const int motor = 9;

const int pot = A0;

void setup() {

  pinMode(motor, OUTPUT);

}

void loop() {

  int potState = analogRead(pot);

  analogWrite(motor, potState);

}

I used a motor with gears because my own motor (without gears) did not create movement as smoothly as I wished it to. It is my understanding that gears, as I used them, increase the force of the movement and decrease its speed. This was ideal for what I wanted to build, given that the motor has to carry a long line of wooden sticks and materials glued to them. Also, the hips’ motion looks better when closer to the speeds at which an actual person can perform them.

The motor, attached to a Pringles’ can as a Pringles’ can cap is attached to it. Conclusion: Pringles are automata-friendly.

The project also includes (2) a system that transforms rotary into linear motion, which I built following this example:

I altered it slightly, by replacing the sliding mechanism on the disk with a crank, as shown below:

This setup creates a slider-crank mechanism, and Moana’s movements are as follows:

 

 

Stupid Pet Trick: Nodding Cockatoo

If you experience difficulties in figuring out the shape, stand three meters away, squint your eyes, tilt your head to the left, and make a 196° degree turn on your tiptoes. That should do it.

The prompt for this project, creating a “stupid pet trick” incorporating analog and digital input and output, made me think of a stupid pet trick from my own home. This is Sisi, my pet cockatoo named after Empress Elizabeth of Austria (fun fact), who imitates others’ nodding motions as shown in the following video:

Guests always find the interaction with Sisi amusing, more so if they whistle and she “replies” with a whistle of her own. Knowing that this is considered a fun trick, I decided to simulate Sisi’s nodding and sounds (which I wasn’t able to get to, unfortunately). For this purpose, I considered using a Neopixels grid on which I could alternate different images or frames of a cockatoo, each in a different position, such that when changing rapidly the Neopixels create the illusion of a moving bird. These changes would be triggered by a distance (IR rangefinder) analog sensor, to detect whether the user moves her/his head. The sensor would thus aid in determining which cockatoo frame to use at each moment.

I couldn’t incorporate sound by the deadline, but I had thought of placing a piezo buzzer behind the Neopixels grid and a microphone near the distance sensor. If the user were to speak near the cockatoo, the bird would “respond” with whistling sounds (the idea could be better implemented with actual recordings of my cockatoo, instead of the tones produced by the buzzer, as suggested by my professor).

The code is as follows, based on the Adafruit Neopixel “simple” example code by Shae Erisson:

#include <Adafruit_NeoPixel.h>
#ifdef __AVR__
 #include <avr/power.h>
#endif

const int PIN = 6;
//output for Neopixels strip

const int NUMPIXELS = 72;
//grid has dimensions 8 x 9 pixels (72 LEDs)

Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);

const int sensor = A5;
//analog input from IR rangefinder

//the following constants are three matrices, each representing one frame (the cockatoo at its highest, in the center or middle position, and at its lowest (the three positions together simulate the nodding motion) 
//each array within the larger array represents one LED, of which its color is defined by RGB values
const int birdUp[][3] = {
 //row 1
 {255, 255, 255},
 {255, 255, 255},
 {255, 127, 39},
 {255, 127, 39},
 {255, 127, 39},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},

//row 2
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},

//row 3
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},

//row 4
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},

//row 5
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},

//row 6
 {0, 0, 0},
 {0, 162, 232},
 {0, 162, 232},
 {0, 162, 232},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 
 //row 7
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {0, 162, 232},
 {140, 39, 241},
 {0, 162, 232},
 {255, 127, 39},

//row 8
 {0, 0, 0},
 {0, 162, 232},
 {0, 162, 232},
 {0, 162, 232},
 {255, 255, 255},
 {255, 242, 0},
 {0, 0, 0},
 {0, 0, 0},

//row 9
 {0, 0, 0},
 {255, 242, 0},
 {255, 242, 0},
 {255, 242, 0},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0}
 };

const int birdMiddle[][3] = {
 //row 1
 {255, 255, 255},
 {255, 255, 255},
 {255, 127, 39},
 {255, 127, 39},
 {255, 127, 39},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},

//row 2
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},

//row 3
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},

//row 4
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},

//row 5
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {0, 162, 232},
 {0, 162, 232},
 {0, 162, 232},
 {0, 0, 0},
 
 //row 6
 {255, 127, 39},
 {0, 162, 232},
 {140, 39, 241},
 {0, 162, 232},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},

//row 7
 {0, 0, 0},
 {0, 0, 0},
 {255, 242, 0},
 {255, 255, 255},
 {0, 162, 232},
 {0, 162, 232},
 {0, 162, 232},
 {0, 0, 0},

//row 8
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 242, 0},
 {255, 242, 0},
 {255, 242, 0},
 {0, 0, 0},

//row 9
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0}
 };

const int birdDown[][3] = {
 //row 1
 {255, 255, 255},
 {255, 255, 255},
 {255, 127, 39},
 {255, 127, 39},
 {255, 127, 39},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},

//row 2
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},

//row 3
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},

//row 4
 {0, 0, 0},
 {0, 162, 232},
 {0, 162, 232},
 {0, 162, 232},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 
 //row 5
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {255, 255, 255},
 {0, 162, 232},
 {140, 39, 241},
 {0, 162, 232},
 {255, 127, 39},

//row 6
 {0, 0, 0},
 {0, 162, 232},
 {0, 162, 232},
 {0, 162, 232},
 {255, 255, 255},
 {255, 242, 0},
 {0, 0, 0},
 {0, 0, 0},

//row 7
 {0, 0, 0},
 {255, 242, 0},
 {255, 242, 0},
 {255, 242, 0},
 {255, 255, 255},
 {255, 255, 255},
 {0, 0, 0},
 {0, 0, 0},

//row 8
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},

//row 9
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0},
 {0, 0, 0}
 };

void setup() {
 pixels.begin();
}

void loop() {
 int distance = analogRead(sensor);
 int distanceNum = round(distance/100);
 //the sensor gives values ranging from around 250 to 650
 //divided by 100 and using the round() function, these values range from 3 to 7, which are more convenient for the program
 if(distanceNum > 4){
 for(int i=0;i<NUMPIXELS;i++){
 int red = birdUp[i][0];
 int green = birdUp[i][1];
 int blue = birdUp[i][2];
 pixels.setPixelColor(i, pixels.Color(red, green, blue));
 pixels.show();
 }
 }
 //if the sensor's value is 5, 6, or 7, the cockatoo appears at its highest (I wanted the range of the highest height to be the largest, given that it is easiest to make out the shape of the bird in this frame)
 else if(distanceNum == 4){
 for(int i=0;i<NUMPIXELS;i++){
 int red = birdMiddle[i][0];
 int green = birdMiddle[i][1];
 int blue = birdMiddle[i][2];
 pixels.setPixelColor(i, pixels.Color(red, green, blue));
 pixels.show();
 }
 }
 //if the sensor's value is 4, then the cockatoo appears at its middle height
 else{
 for(int i=0;i<NUMPIXELS;i++){
 int red = birdDown[i][0];
 int green = birdDown[i][1];
 int blue = birdDown[i][2];
 pixels.setPixelColor(i, pixels.Color(red, green, blue));
 pixels.show();
 }
 }
 //if the sensor's value is 3, then the cockatoo appears at its lowest height
 }

To create the grid, I connected nine strips of eight Neopixels each with soldered wires.

This is how the strips of Neopixels looked after I joined them, placed on a beautiful background that steals the show.

I found the image that I “translated” into the LEDs online. I edited it such that it was easy to pixelate, and altered the colors so that they didn’t appear to blend (similar color tones are difficult to distinguish for adjacent Neopixels). These four images demonstrate the process to reach the ideal pixelated cockatoo:

I placed the grid on a piece of wood, and created a pixelated tree trunk (made of colored craft wood sticks) under it, to give the illusion that the cockatoo is perched on a tree. The grid is covered with a somewhat translucent paper, to diffuse the lights and make the image’s recognition easier. The distance between the paper and the lights aids in the diffusion, and it would have been better to increase it just a bit more in this case. Nevertheless, the image turned out to be clear enough. The following picture shows the lit cockatoo (at its highest position, determined by one of the “frames”) over the tree. The distortion of the lights was caused by my phone’s camera; the cockatoo’s shape is actually clearer.

This is the complete setup, where the distance sensor is placed on the white box on the left, the Neopixels grid is on the right, and the RedBoard that connects both (as well as the laptop that powers it) is on the chair in the middle.


The sensor is placed in this arrangement because of two reasons. I chose to put the sensor inside the frame because it allows me to control the  values obtained from it. IR rangefinders work in such a way that after a certain point, the values it reads are reflected. For instance, if I place my hand over the sensor and gradually raise it, so as to increase the distance between the two, the values might read 250, …, 300, …, 400,… 500, …, 600, …, 500, … 400, …, 300, …, 250, … Thus, they are reflected around about 600, and the sensor cannot straightforwardly differentiate between the repeated values. The frame limits the sensor’s readings from about 250 to 650, thus eliminating the problem of the reflected values.

The sensor is also on top of a large box because I considered having the user move her/his head to trigger the cockatoo’s motion. Thus, I would need to have a structure that allowed this movement to occur comfortably. Just the frame wouldn’t have done it: placing it on a table, for example, would have required the user the bend in order to nod over the sensor. The tall box facilitated this aspect of the interaction. However, I decided to switch the motion from the head to the hands. Firstly, not all users’ heads will fit inside the frame, and even if they do, the movement is restricted. Secondly, it is easier to control the hand’s placement over the sensor’s beam, which is quite narrow, than the head’s.

This is the cockatoo as it nods, activated by a hand:

 

Dead Man’s Music Box

The instrument I created for this assignment is the first step towards a bigger project that I’m eager to make (if I can), which I have been thinking of for a long time.

The Inspiration

This is Davy Jones’s heart inside the Dead Man’s Chest.

The image, as well as the character, come from Walt Disney Pictures’ 2006 film Pirates of the Caribbean: Dead Man’s Chest. The following is the Wikipedia entry for Davy Jones, a clear explaination of who he is and why his heart is kept in a chest:

In the story, his original purpose was to carry souls of those who died at sea from this world to the next on his vessel. He was charged with this noble and just duty by his one true love, the sea goddess Calypso. For every ten years at sea he could spend one day on land to be with her. Ten years after first being charged with the duty, Jones prepared to be reunited with his true love, but was heartbroken and enraged when she did not appear. Unable to deal with the sadness of Calypso’s betrayal, Jones, through some unknown supernatural means, ripped out his heart and locked it in a chest, burying it…

I’m writing about this old guy’s heart because I really, really really, really really really like “Davy Jones”, the movie’s character theme composed by Hanz Zimmer.

Inspired by Pirates of the Caribbean and Zimmer, I wanted to create a music box that plays the first portion of this piece, presented as if it were the Dead Man’s Chest (therefore, with a “beating” heart inside it).

The Circuit and Code (or Music and Lights)

The main feature of this project is that the music and the lights/colors occur together, the latter following the former’s structure. Thus, the music and lights help create the image of the heart’s beat.

To code the music, which is produced by piezo buzzers in the circuit, I used the piano sheet music for “Davy Jones”. This gave me not only the notes, but also the duration of each. It also provided me with the opportunity to make the music box more complex: instead of just the “main” melody (I apologize for ignoring a better term), written on the upper staff, I could also incorporate the notes from the lower staff. Thus, my music box could play both the right-hand and the left-hand piano notes for this piece.

This came with its own issues, mainly because my code loops through the notes in each staff to carry out its functions. Given that the staves’ notes don’t correspond to each other, in terms of quantity and durations, looping through both was impossible. I attempted to loop through the measures in the staves, which are equal in both cases, but this proved to be overly complicated for me.

I solved the issue using two RedBoards, thus running two codes, one per piezo buzzer. In doing this, I learned that the two circuits need a common ground (meaning, the grounds of both have to be connected), just as with circuits that are controlled by the same RedBoard. Failing to notice this at first, the readings of my analog sensors were greatly altered, and weird stuff was happening. But allas, it was fixed (shout-out to James!).

Circled in red: right piezo buzzer. Circled in light green: left piezo buzzer. Circled in purple: RGB LEDs. You have to squint your eyes to see the circles. Sorry ’bout that.

In terms of light, I programmed two RGB LEDs so that they change color according to changes in the notes. They both have red as the base color (meaning red’s value is 255, while green and blue are 0). However, the “left-hand” LED’s green values change, as well as the “right-hand” LED’s blue values. These alterations follow the increments and reductions of frequency in the sound (changes of notes), such that a higher frequency leads to a greater value for green and blue, and a lower frequency to a lower color value (it’s more noticeable than in the following video, my phone is not too great for LED recording:/).

These are the codes, written after Tom Igoe’s Arduino tone() Tutorial (they both mention the use of a potentiometer and a switch, which I’ll explain next):

Right:

#include "pitches.h"

const int knob = A0;
//potentiometer
const int power = 8;
//swtich

const int red = 3;
const int green = 5;
const int blue = 6;
//LED

int right[] = {
 NOTE_D4, NOTE_E4, NOTE_F4, NOTE_G4, NOTE_A4, NOTE_C5, NOTE_AS4, NOTE_A4,

NOTE_A4, NOTE_AS4, NOTE_C5, NOTE_D5, NOTE_AS4, NOTE_A4, NOTE_G4, NOTE_A4,

NOTE_AS4, NOTE_C5, NOTE_A4, NOTE_F4, NOTE_G4, NOTE_AS4, NOTE_A4, NOTE_F4, 
 NOTE_D4, NOTE_E4, NOTE_C4, NOTE_A3, NOTE_E4, NOTE_D4
};
//upper staff notes
//notes referenced from "pitches.h" file

int rightDurations[] = {
 2, 4, 2, 4, 2, 8, 8, 1.333333333333333333333,

2, 4, 2, 8, 8, 2, 4, 1.333333333333333333333,

2, 4, 2, 4, 2, 8, 8, 2, 4, 2, 4, 2, 4, 1.333333333333333333333
};
//note durations


void setup() {
 pinMode(red, OUTPUT);
 pinMode(green, OUTPUT);
 pinMode(blue, OUTPUT);
 pinMode(power, INPUT);
 Serial.begin(9600);

for (int thisNote = 0; thisNote < sizeof(right); thisNote++) {
 //for loop goes through each note individually
 int powerControl = digitalRead(power);
 //value contains information on whether the switch is on or off
 int knobValue = analogRead(knob);
 //value contains information on where the potentiometer is (how it was turned)
 int mappedValue;
 if(knobValue < 341){
 mappedValue = 3;
 }
 else if(knobValue < 682){
 mappedValue = 2.2;
 }
 else{
 mappedValue = 1.3;
 }
 //maps potentiometer's values to values that will be used to pause between notes, thus affecting the speed of the music
 //I didn't use the map() function because the values something vary slightly, and that made the music sound odd. It is better to set intervals in this case
 int rightDuration = 1000 / rightDurations[thisNote];
 if(powerControl == HIGH){
 tone(12, right[thisNote], rightDuration);
 int mappedBlue = map(right[thisNote], round(NOTE_A3/10), round(NOTE_D5/10), 0, 255);
 analogWrite(red, 255);
 analogWrite(green, 0);
 analogWrite(blue, mappedBlue);
 //if the switch is on, the note will be produced, as well as the LED color
 }
 else{
 tone(12, 0, rightDuration);
 analogWrite(red, 0);
 analogWrite(green, 0);
 analogWrite(blue, 0);
 //if the switch is off, the note will be muted, and the LED will be off
 }
 int pauseBetweenNotes = rightDuration * mappedValue;
 delay(pauseBetweenNotes);
 noTone(12);
 analogWrite(red, 0);
 analogWrite(green, 0);
 analogWrite(blue, 0);
 }
}

void loop(){
}

Left:

(Same as Right except for the notes, taken from the lower staff in the sheet music)

#include "pitches.h"

const int knob = A0;
const int power = 8;

const int redL = 3;
const int greenL = 5;
const int blueL = 6;

int left[] = {
 NOTE_D3, NOTE_A3, NOTE_D3, NOTE_A3, NOTE_D3, NOTE_A3, NOTE_D3, NOTE_A3,

NOTE_D3, NOTE_A3, NOTE_C3, NOTE_G3, NOTE_D3, NOTE_A3, NOTE_D3, NOTE_A3,

NOTE_G3, NOTE_D4, NOTE_C4, NOTE_D3, NOTE_A3, NOTE_E3, NOTE_G3, NOTE_CS3,
 NOTE_D3, NOTE_A3, NOTE_C3, NOTE_E3, NOTE_C3, NOTE_E3, NOTE_D3, NOTE_F3, 
 NOTE_D3, NOTE_F3
};

int leftDurations[] = {
 4, 2, 4, 2, 4, 2, 4, 2,

4, 2, 4, 2, 4, 2, 4, 2,

4, 4, 4, 4, 2, 4, 4, 4, 4, 2, 4, 2, 4, 2, 4, 2, 4, 2
};

void setup() {
 pinMode(redL, OUTPUT);
 pinMode(greenL, OUTPUT);
 pinMode(blueL, OUTPUT);
 Serial.begin(9600);

for (int thisNote = 0; thisNote < sizeof(left); thisNote++) {
 int powerControl = digitalRead(power);
 int knobValue = analogRead(knob);
 int mappedValue;
 if(knobValue < 341){
 mappedValue = 3;
 }
 else if(knobValue < 682){
 mappedValue = 2.2;
 }
 else{
 mappedValue = 1.3;
 }
 int leftDuration = 1000 / leftDurations[thisNote];
 if(powerControl == HIGH){
 tone(12, left[thisNote], leftDuration);
 int mappedGreen = map(left[thisNote], round(NOTE_C3/10), round(NOTE_D4/10), 0, 100);
 analogWrite(redL, 255);
 analogWrite(greenL, mappedGreen);
 analogWrite(blueL, 0);
 }
 else{
 tone(12, 0, leftDuration);
 analogWrite(redL, 0);
 analogWrite(greenL, 0);
 analogWrite(blueL, 0);
 }
 int pauseBetweenNotes = leftDuration * mappedValue;
 delay(pauseBetweenNotes);
 noTone(12);
 analogWrite(redL, 0);
 analogWrite(greenL, 0);
 analogWrite(blueL, 0);
 }
 }

void loop(){
}
The User

There are three things the user can do with this music box, making it unconventional:

– Play the notes of just the right hand, just the left hand, or both together

– Change the speed of the music (there are three speeds)

– Once they’re playing, mute the notes of the right hand, the left hand, or    both together

Push buttons restart each set of notes, a potentiometer controls the speed, and switches mute the sound (marked with the convention of 0 to “turn off” and 1 to “turn on”).

Circled in red: right push button. Circled in light green: left push button. Circled in light blue: potentiometer. Circled in white: switches

The following video shows how these features work:

See that weird thing that happens at the end of the potentiometer bit? A friend’s hypothesis is that it has to do with the voltage. Regardless, I like it a lot: it makes it seem look like the heart is dying at the end, turnig off in a somewhat organic way. This is kind of the same reason why I didn’t implement switches to fully stop the music once it has started. You can mute it… but the heart keeps on beating until it dies, reaching its natural end.

On Unspecificity

(Response to the talk “The Norm of Design” by Roberto Casati)

Casati structured his talk on design around triads. These are the ones I included in my notes, as they were noted (transition from paper to PNG files courtesy of Microsoft Paint):

Casati’s introduction on how he merges philosophy (his area of expertise), research, and design
How this particular talk was structured (points he would focus on)

While explaining the difficulties of defining design, Casati said the following: “It is impossible to define anything that you don’t create with the definition.” He was referring to paradigms, and mentioned two ends of the spectrum. The first was mathematics, where all concepts are created following their definition. The second was a chair. He asked the audience to think of definitions for what a chair is, and guaranteed that he could come up with objects that could defy any definition (either because they didn’t fit the definition and were chairs, or because they fit the definition but weren’t chairs). The problem with defining design, he stated, is its unspecificity.

Casati’s argument about unspecificity and paradigms made me think of a similar case, that of culture as a term. Some years ago, I worked on an assignment in which I had to discuss the shortcomings of official definitions of culture, and even though putting my thought into words proved to be quite difficult (because, again, unspecificity), I could easily understand why the definitions I was given seemed to either be too vague and general, or too specific and failing to convey all aspects of culture.

Casati then proceeded to say that we shouldn’t deal with definitions, so we should think of normativities instead. He compared design, engineering, and art, concepts that relate to each other but which often cause confusion.

Design in comparison to engineering and art (this is supposed to be a visual representation of how they relate, as I understood it)

It was this point of the talk, it seemed to me, that caused the most “controversy”, because audience members sought an absolute definition of design that Casati couldn’t give them (which he had claimed he wasn’t able to from the start). Individuals sought a definitive, logical system with which to distinguish the concepts of the triad from one another, holding on to the notion that it shouldn’t be possible for an example to illustrate two or three of the concepts at once.

People are uncomfortable with ambiguity and fluidity. That’s one of the lessons from this talk that stands out the most. It reminded me of Don Norman’s The Design of Everyday Things, where he discusses the differences between engineering and human-centered design in approaching a problem. Audience members seemed to refuse to accept that there’s something intuitive about design, something which a mathematical definition might not explain, but which cognitive science might. It also made me think of Graham Pullin’s Design Meets Disability, where he talks about the problems of universal design, which tries to fit everyone’s needs into one fixed system instead of adapting each item’s design to each individual. People don’t like unspecificity, because it feels like we can’t control it. But what if unspecificity works best, forcing us to deal to each new (design) situation with an open mind?

Fashionable Eyes and Teeth

(Response to Design Meets Disability by Graham Pullin)

In one of my classes this week, we discussed the following image:

Mu'in. Portrait of Riza-i-Abbasi. 1673. Princeton University..jpg
Mu’in: Portrait of Riza, Isfahan, 1673.

This is a portrait of famous Persian artist Riza, made by his pupil Mu’in in 1673. At the time, illustrations were incredibly detailed, which is particularly impressing considering how small they were (they served to accompany text in manuscripts). Though, it is speculated that Riza wore spectacles to aid him in creating almost imperceptible decorations and details in his work.

The reason I bring it up is that I encountered this image after reading Graham Pullin’s chapters, and I was reminded of his brief history of eyeglasses. He explains that it was until the nineties that there was a “shift [in the public’s] perspective” of glasses as medical aid to glasses as a socially accepted accessory.

However, this and many other illustrations, drawings, and paintings from earlier centuries show that glasses have been around for a long time (not that Pullin is disputing this) and they have been associated to “positive” or “respectable” characteristics. Riza, as an illustrator, needed spectacles to protect his vision. And heaven forbid Riza’s eyes get damaged, for he was a rock star in Sha ‘Abbas’s (ruler at the time) court.

A bonus example: “The oldest known pictorial representation of eyeglasses is a fresco in the Chapter House of the Dominican Monastery attached to the Basilica of San Niccolõ in Treviso. It was painted by Tommaso da Modena (1325-1379) in 1352 and shows  Cardinal Hugh of Provence (1200-63) wearing a pair of rivet spectacles. What makes this painting interesting is the fact that the Cardinal died before glasses were invented but the painter added spectacles to his fresco as a sign of old age and scholarship.”

I have to admit that reflecting on this makes me feel a bit pessimistic. Glasses have been around for centuries, and it was until two decades ago that they became “stylish”?

I considered another form of medical aid that is being influenced by “fashionable” design. These are old braces:

This is the kind of gear that a movie’s nerdy character would sport, and then she would get bullied by a girl with perfect teeth… supporting Pullin’s argument.

These are new ones:

Apparently, braces have also been around for a long time, and it is until now that an effort to design them so that they stand out in a positive way is made.

Why glasses and braces? My hypothesis is that they have become common: nowadays, not only can more people be diagnosed with conditions that require these (either because the products are developed to fix more issues, or because the technologies to diagnose such issues have become more precise), but they also become more affordable, I believe. More people get glasses and/or braces because they are seen as necessities. Is this why we have agreed to finally stop discriminating against their aesthetics and start to improve them?

I guess this was just a long way to say that I agree with Pullin. We have a problem with social inclusion of minorities, which is reflected in design. Is it until the minorities become too large, common enough for us to feel “comfortable”, that we accept disabilities and the objects that represent them? Two people in my family wear hearing aids, and I’ve seen them transform throughout the years, becoming tinier and more discrete. Meanwhile, as a thirteen year old, I couldn’t wait to get my braces and change their colors every month.

 

 

Interpol Nap Time

This week’s assignment asked to control an LED in an unexpected way. Unexpected situations are often cause for alarm.

And there it was: I would make an alarm.

I would “compel” the user to do something (activate an analog sensor) and trigger an alarm, preferrably a hidden one – thus the unexpected factor.

The following images and videos show the story that I attempted to create with this assignment, the sensor I used, and the LEDs’ response. I set up a circuit with red and blue LEDs, as well as a soft potentiometer. The potentiometer is inside a cardboard envelope, such that if a person introduces their hand in the envelope, they will apply pressure on the sensor. The further inside the hand goes, the greater the value given by the potentiometer (given that values increase or decrease along the strip). The envelope (brace yourselves) “contains top secret documents that can only be read by Interpol agent Ana B. Pepper, who happens to have fallen asleep on top of her paperwork, causing the envelope to fly off and land on the floor.”

I wrote that, I’m not quoting anyone. But it looks more official with the quotation marks.

A friend once told me about a woman called Ana (or Anna) Pepper who had mutliple middle names, one per letter of the alphabet. That’s all my character’s name means. And I added Interpol to the mix because my first thought was the FBI, but that’s too cliché. So, Interpol.

Essentially, I wanted to create a scenario in which an alarm wouldn’t be expected, but in which it does make sense (the protection of confidential information by an international police organization is anticipated, even if not with an alarm such as this one). Thus, the LEDs react to the potentiometer’s values, making the red and blue lights blink (just like in a police car). The higher the sensor’s values, the faster the blinking.

SparkFun soft potentiometer (sensor triggered by pressure applied along the strip)
Soft potentiometer placed inside a cardboard envelope
“Top Secret” envelope from above (aka my feeble attempt to fool my users, aka why am I relying on people’s criminal impulses?)
Ana’s desk and envelope from above

With more time, I would like to add police siren sounds and make the LEDs turn on in the pattern of an actual police car light, given that the response is very simple as of right now.

The greatest complication regarding the Arduino code was the fact that I get seemingly random values from the potentiometer when no pressure is applied on it (I originally thought the envelope might be the cause for this, but I tested the sensor without it and the values still appeared).

Values from potentiometer (no pressure applied)

Thus, I had to come up with a way to discriminate between these random values and the ones obtained when touching the potentionmeter. If I hadn’t, then the LEDs would be constantly blinking, given that their “command” to blink is related to the sensor’s values.

The code is as follows:

const int sensor = A5;
const int led1 = 4;
int led1State = LOW;
const int led2 = 5;
int led2State = LOW;
const int led3 = 6;
int led3State = LOW;
const int led4 = 7;
int led4State = LOW;
const int led5 = 8;
int led5State = LOW;
const int led6 = 9;
int led6State = LOW;
const int led7 = 10;
int led7State = LOW;
const int led8 = 11;
int led8State = LOW;
const int led9 = 12;
int led9State = LOW;
const int led10 = 3;
int led10State = LOW;
//analog input (soft potentionmeter) and digital output (LEDs)


int value = -100;
int counter = 0;
bool checks[3] = {false, false, false};
//variables allow code to check if the soft potentiometer has detected the same value three consecutive times. Only then will the LEDs turn on

long previousMillis = 0;
//millis() is used in the loop to enable blinking (as we did in class)


void setup() {
 pinMode(led1, INPUT);
 pinMode(led2, INPUT);
 pinMode(led3, INPUT);
 pinMode(led4, INPUT);
 pinMode(led5, INPUT);
 pinMode(led6, INPUT);
 pinMode(led7, INPUT);
 pinMode(led8, INPUT);
 pinMode(led9, INPUT);
 Serial.begin(9600);
}

void loop() {
 int sensorValue = analogRead(sensor);
 Serial.println(sensorValue);
 if((sensorValue <= (value+10))&&(sensorValue >= (value-10))){
 //the code allows a difference of 10 units when checking for the consecutive values
 counter++;
 //if sensor value is the "same" as the value stored from the previous loop (or -100 for the first loop, a value that the sensor will never reach), then the counter is incremented by one (1/3 of the checks needed to light the LEDs)
 if(checks[2] == false){
 checks[counter] = true;
 //if less than three checks are true, then the next one is made true
 }
 else{
 //if there are already three checks
 int mappedValue = map(sensorValue, 1023, 0, 10, 200);
 int constrainedValue = constrain(mappedValue, 50, 500);
 //variables map the sensor values to the LEDs' blinking times
 
 unsigned long currentMillis = millis();

if((currentMillis - previousMillis) > constrainedValue){
 if(led1State == LOW){
 led1State = HIGH;
 led2State = HIGH;
 led3State = HIGH;
 led4State = HIGH;
 led5State = HIGH;
 led6State = HIGH;
 led7State = HIGH;
 led8State = HIGH;
 led9State = HIGH;
 led10State = HIGH;
 }
 else{
 led1State = LOW;
 led2State = LOW;
 led3State = LOW;
 led4State = LOW;
 led5State = LOW;
 led6State = LOW;
 led7State = LOW;
 led8State = LOW;
 led9State = LOW;
 led10State = LOW;
 }
 digitalWrite(led1, led1State);
 digitalWrite(led2, led2State);
 digitalWrite(led3, led3State);
 digitalWrite(led4, led4State);
 digitalWrite(led5, led5State);
 digitalWrite(led6, led6State);
 digitalWrite(led7, led7State);
 digitalWrite(led8, led8State);
 digitalWrite(led9, led9State);
 digitalWrite(led10, led10State);
 //make LEDs blink dependig on sensor values

previousMillis = currentMillis;
 }
 }
 }
 else{
 checks[0] = false;
 checks[1] = false;
 checks[2] = false;
 counter = 0;
 digitalWrite(led1, LOW);
 digitalWrite(led2, LOW);
 digitalWrite(led3, LOW);
 digitalWrite(led4, LOW);
 digitalWrite(led5, LOW);
 digitalWrite(led6, LOW);
 digitalWrite(led7, LOW);
 digitalWrite(led8, LOW);
 digitalWrite(led9, LOW);
 digitalWrite(led10, LOW);
 //if no three consecutive values are equal, the LEDs remain off
 }
 value = sensorValue; 
 //saves sensor value to compare it to new value in the next loop
}

It’s Like Theater

(Response to “Making Interactive Art: Set the Stage, Then Shut Up and Listen” and “Physical Computing’s Greatest Hits (and misses)” by Tom Igoe)

While reading the introduction of “Making Interactive Art”, theater was in my mind and I was conflicted. I have participated in a couple of theater productions (as crew member) and I have also designed an online game (for an Interactive Media class). The latter experience taught me how essential it is to understand how users approach your creation and try to interact with it. The last thing you want, I learned, is a confused user who has no clue what to do. Theater taught me that instances in plays and performances can be cryptic (even to the director themselves), but that these moments work as long as they incite an aesthetic experience and an “emotional interpretation” (in Igoe’s words). I was trying to reconcile the two, because when I think of grand interactive media projects I’d like to develop, a bit of theater is always added to the mix; however, the first three paragraphs of the post made me feel that interactive art and theater have different ways of conversing with users/audience (going back to our first reading about interactivity, which Igoe’s notion of art reminds me of).

But as I continued reading, Igoe did the reconciling for me. I forgot that as a director who conceives a play or performance, your first “users” are not the audience members: they’re the actors. I like the idea of users as actors in my creation, who must understand how to navigate my piece with complete clarity, but who have the freedom to do so in their style and with their own interpretations.

With my thoughts focused on theater, I had a very particular reaction to the following quote from Igoe’s second post: “Sometimes when people learning about physical computing hear that a particular idea has been done before, they give up on it, because they think it’s not original.”

How many productions and adaptations of Hamlet have been put on stage? The answer is a ridiculous amount. More and more directors want to develop their own versions of Hamlet, show the audience their own interpretations of it, explore it in different media, so on and so forth. They do it, and it’s fine. Let it be the same with physical computing ideas.

On the Unwanted Consequences of Numbness

(Response to “A Brief Rant on the Future of Interaction Design” and “Responses: A Brief Rant on the Future of Interaction Design” by Bret Victor)

Bret Victor’s blog post reminds me of an article I read for a class last year, about the reason behind the 2009 crash of Air France Flight 447.

I agree with Victor’s opinion that in the current development of tools, human capability is the “third neglected factor”. He introduces the notion of “permanent numbness”, arguing that current interactive technologies don’t stimulate our bodies’ own abilities as they should.

The fact that our bodies evolved for thousands of years to accomplish adaptations such as the multiple nerve endings in our fingers, which are extremely advantageous in manipulating objects and understanding our surroundings, is what reminded me of the article about the crash. In Victor’s follow-up post, he cites neuroscientist Matti Bergström, who explains that the nerve endings in our fingertips need to be stimulated and developed from childhood. Else, the individual become “finger-blind”.

In “Crash: How Computers are Setting Us Up for Disaster”, Tim Harford states that the Air France airplane crashed because the pilots didn’t understand the instructions of the computer that piloted the aircraft. The reason was that the computer usually didn’t require assistance; signals such as the one they received are exceptions, emitted in rare cases. Thus, pilots don’t really get much practice in dealing with emergencies, and that’s precisely the problem. When an emergency occurs, the safety of passengers and crew depends entirely on the pilots’ knowledge and skills. If these are not practiced, given to a machine to exercise instead of humans, then the pilot becomes “blind” and unaware of how to handle uncommon scenarios.

The situation is extreme compared to Victor’s examples, but the rant and the article express the same concern. Technologies that disable us (as in, that render us useless) are not the tools that we should look forward to. We should develop technologies that aid us in our tasks, but that also make full use of our capacities and hopefully strengthen them.