These readings were very eye-opening in some regards, but I also felt that they were a bit closed-off in others. With our many discussions on what it means for something to be well-designed, we have had to start thinking about our works beyond just their function. Now we are bringing physiology into the equation on top of the prior psychological aspects. I have some idea of how miraculous the human body is and how much work it takes to try and replicate the simplest of actions via technology, but the examples posed about how we use our hands painted a much more intimate picture than I had considered. For example, I might think about how I struggle to play FPS games on a controller whereas several of my friends can’t stand using a mouse and keyboard. The broader significance of tactile feedback would be largely lost in that simple case, let alone the discussion on how input devices might look in 20 years.

Speaking of, I was much more uncertain about how we might work towards this brighter future. This post from 2011 has plenty of thoughts on the matter, but the landscape has changed greatly since then. For example, a good portion of the reading focuses on how touchscreens fall flat of delivering the true experience, but I would argue that many people feel more comfortable with an e-book than a real one, especially so for the younger demographic that grew up with a tablet in hand. The discussion of voice also seems rather shortsighted in hindsight, given that Siri first released in 2010 and was shortly followed by Alexa in 2014. Nowadays you can even push voice-based systems to the point of live-translating speech or leaning on LLMs to achieve goals in the realm of creating and understanding. Lastly, on the subject of brain interfaces, I felt that the author was a bit too pessimistic about things. Companies like Neuralink still fall short today, but they can be hugely impactful for people that can’t rely on their bodies. I can definitely agree that nature is the ultimate inventor, but I don’t think that brain-computer interfaces should be disregarded out of fear that we will all end up forsaking the real world. Either way, with the rate that certain technologies have progressed over the past few years, it’s hard to even imagine what direction interfaces might evolve in.

Design:
I used a slide switch as the digital sensor, and a potentiometer + photometer as the analog sensors. The slide switch was originally just an on/off switch, but now allows the instrument to switch between two modes (which currently shifts the octave).  The potentiometer acts as a volume control, while the photometer provides an additional input towards the tone frequency.
The physical component is a simple sort of keyboard made from paper and copper tape. It works by passing current through one of five different resistors (1k, 10k, 100k, 470k, 1m) and using analogRead() to identify which key was pressed. The five keys correspond to the notes A4/5 through E4/5. The initial steps of wiring the circuit and writing the code were fairly painless, which was not the case for converting it into its final result. I think it definitely suffered from my lack of ability with music as well as arts and crafts.

Diagram:

Code:

/*
  Musical Instrument
*/

#include "pitches.h"

// // Global Variables
const int LIGHT_PIN = A0;
const int TOUCH_PIN = A5;
const int MODE_PIN = 2;
const int SOUND_PIN = 8;
int low[] = {NOTE_A4, NOTE_B4, NOTE_C4, NOTE_D4, NOTE_E4};
int high[] = {NOTE_A5, NOTE_B5, NOTE_C5, NOTE_D5, NOTE_E5};



void setup() {
  Serial.begin(9600);
  pinMode(LIGHT_PIN, INPUT);
  pinMode(TOUCH_PIN, INPUT);
  pinMode(MODE_PIN, INPUT);
  pinMode(SOUND_PIN, OUTPUT);
}

void loop() {
  // // Read digital/analog
  int modeVal = digitalRead(MODE_PIN);
  // Serial.println(modeVal);
  int lightVal = analogRead(LIGHT_PIN);
  // Serial.println(lightVal);
  int touchVal = analogRead(TOUCH_PIN);
  Serial.println(touchVal);
  
  // // Choose note based on touch input
  // 1k = 932
  // 10k = 512
  // 100k = 92
  // 470k = 20
  // 1m = 8
  int x; int mapped;
  if (touchVal < 4) {noTone(SOUND_PIN); return;
  }
  else if (touchVal < 16) {x = 0;}
  else if (touchVal < 64) {x = 1;}
  else if (touchVal < 128) {x = 2;}
  else if (touchVal < 768) {x = 3;}
  else if (touchVal < 1024) {x = 4;}
  // Serial.println(x);

  // // Choose high/low range based on mode
  int note;
  if (modeVal) {
    note = low[x];
    mapped = map(lightVal, 400, 1200, 0, 2500);
  }
  else {
    note = high[x];
    mapped = map(lightVal, 400, 1200, 2500, 5000);
  }
  // // Play sound
  tone(SOUND_PIN, note);
}

 

 

For this week’s assignment, we were tasked with using Arduino to create a musical instrument. Working in pairs, Kashish and I decided to create a piano based on the tone() function we had explored earlier in class. In our project, we wanted each button switch to correspond to a different note from a piano, so that it could be “played”.

We were asked to use both an analogue and digital component for the assignment; while the digital component was simple enough with the buttons, we decided to use a pontentiometer as our analogue component, and used it to control the pitch of the notes being produced by each button.

The components we used were:

• Arduino Uno
• Breadboards
• Jumper cables
• 10k Ohm resistors
• Push buttons
• 5V speaker

Here is an image of our project, and the schematic:

Our code:

#include "pitches.h"

const int potPin = A0;          // Potentiometer on A0
const int buzzerPin = 8;        // Speaker on D8
const int buttonPins[] = {2, 3, 4, 5, 6, 7, 9, 10}; // C4-C5 buttons
const int baseNotes[] = {NOTE_C4, NOTE_D4, NOTE_E4, NOTE_F4, NOTE_G4, NOTE_A4, NOTE_B4, NOTE_C5};

void setup() {
  // Keep external 10k resistors
  for (int i = 0; i < 8; i++) {
    pinMode(buttonPins[i], INPUT); 
  }
  pinMode(buzzerPin, OUTPUT);
}

void loop() {
  // potentiometer value
  int potValues[5] = {0};
  int potIndex = 0;
  potValues[potIndex] = analogRead(potPin);
  potIndex = (potIndex + 1) % 5;
  int octaveShift = map( // mapping potentiometer values as a shift in octave
    (potValues[0] + potValues[1] + potValues[2] + potValues[3] + potValues[4]) / 5,
    0, 1023, -2, 2
  );

  // Check buttons to play notes
  bool notePlaying = false;
  for (int i = 0; i < 8; i++) {
    if (digitalRead(buttonPins[i]) == HIGH) {  
      int shiftedNote = baseNotes[i] * pow(2, octaveShift);
      tone(buzzerPin, constrain(shiftedNote, 31, 4000)); 
      notePlaying = true;
      break;
    }
  }

  if (!notePlaying) {
    noTone(buzzerPin);
  }
  delay(10); 
}

Videos of our project:

Playing Happy Birthday

Adjusting the Potentiometer

A challenge we faced was definitely our lack of musical knowledge. Neither Kashish or I are musicians, and as such, we had to do a lot of research to understand the terminology and theory, such as the notes, and how to adjust the octave using the potentiometer. We then also had to figure how to reflect these findings within our code.

Overall though, we had a great time making this project, and then executing our idea.

Bret Victor’s “A Brief Rant on the Future of Interaction Design” calls out future interfaces to be mere pictures under glass. He argues that this approach is ignoring the amazing capabilities of the human hands. Current trends focus too much on visual interactions, neglecting our sense of touch. Hands are powerful tools for a sense of dexterity and manipulation, something currently absent in a lot of touch based technologies. He takes inspiration from Alan Key’s early vision of the iPad, and encourages designers to explore our mediums that can potentially improve user experiences by engaging us both visually and sensually. A lot of his argument actually makes sense. It is human nature, from being babies to be attracted to bring screens, but our immediate reaction to anything is to touch it, see if it turns, or moves, or if its a switch or a knob. We always seek some sense of physical manipulation in objects, and I do think modern technologies are limiting this to a far more visual approach. Even when I type essays, I prefer using a laptop keyboard over my iPad screen, because I genuinely like the touch-and-feel of clicking and clacking on the keyboard keys- it somehow motivates me to write better. Even though this isn’t a full usage of hands and body movements, this minute degree of change in physical interaction itself makes me more interested. “With an entire body at your command, do you seriously think the Future Of Interaction should be a single finger?” – this statement really opened my eyes to how much technology has been reshaped to fit users to a limited physical experience. 

In the response article, he answers some of the questions people had. I can admit that I too was unsure of the stylus situation. And I’m not sure how styluses can be made to be dynamic. I fully agree with him on the voice input part- I never found that to be appealing or better. Overall, I’d say Vistor’s rant on the future of interaction design is completely justifiable- to be futuristic doesn’t mean to be deprived of sensuality. Rather embracing the movements of our hands and channeling a sense of physical interaction can definitely aid us in improving the future of interaction.

Concept

For this project, I tried to build a simple lighting system using an LDR (light sensor), a push-button, and two LEDs. One LED changes brightness depending on how bright the room is, and the other lights up to show when I’ve manually taken control.

I wanted to manually override the automatic light control with the press of a button—so if I want the light to stay at a fixed brightness no matter how bright it is outside, I just hit the button. Press it again, and the automatic behavior comes back.

I used TinkerCad for the circuit simulation.

Video

How It Works

1. 1. The LDR is connected to pin A0 and tells the Arduino how bright the environment is.

   2. Based on this reading, the Arduino maps the value to a number between 0 and 255 (for LED brightness).

   3. The LED on pin 9 gets brighter when it’s dark and dims when it’s bright—automatically.

   4. I also wired a button to pin 2. When I press it, the system switches to manual mod

      • In this mode, the LED stays at medium brightness, no matter the light level.

      • An indicator LED on pin 13 lights up to let me know I’m in manual mode.

   5. Pressing the button again switches back to automatic mode.

Code

// Pin Definitions
const int ldrPin = A0;         // LDR sensor connected to A0
const int buttonPin = 2;       // Push-button connected to digital pin D2
const int pwmLedPin = 9;       // PWM LED for the ambient light effect
const int overrideLedPin = 13; // Digital LED for manual override indicator

// Variables
bool manualOverride = false;   // Tracks if the override mode is active
int lastButtonState = LOW;     // With external pull-down, default is LOW
unsigned long lastDebounceTime = 0;
const unsigned long debounceDelay = 50; // Debounce time in milliseconds

void setup() {
  pinMode(ldrPin, INPUT);
  pinMode(buttonPin, INPUT);
  pinMode(pwmLedPin, OUTPUT);
  pinMode(overrideLedPin, OUTPUT);
  
  // Start with manual override off, LED off
  digitalWrite(overrideLedPin, LOW);
  Serial.begin(9600);
}

void loop() {
  // Read the LDR Sensor
  int ldrValue = analogRead(ldrPin);
  
  // Map the LDR value to PWM brightness (0-255).
  // Darker environment (low ldrValue) yields a higher brightness.
  int pwmValue = map(ldrValue, 0, 1023, 255, 0);
  
  // Handle the Push-Button for Manual Override with Debouncing
  int reading = digitalRead(buttonPin);
  if (reading != lastButtonState) {
    lastDebounceTime = millis();
  }
  if ((millis() - lastDebounceTime) > debounceDelay) {
    //Unpressed = LOW, pressed = HIGH.
    if (reading == HIGH && lastButtonState == LOW) { // button press detected
      manualOverride = !manualOverride;
      // Update the indicator LED accordingly
      digitalWrite(overrideLedPin, manualOverride ? HIGH : LOW);
    }
  }
  lastButtonState = reading;
  
  // LED Behavior Based on Mode 
  if (manualOverride) {
    // In manual override mode, set LED to a fixed brightness.
    analogWrite(pwmLedPin, 128);
  } else {
    // Set brightness according to ambient light measured by the LDR.
    analogWrite(pwmLedPin, pwmValue);
  }
  
  // Debug output
  Serial.print("LDR Value: "); Serial.print(ldrValue);
  Serial.print(" | PWM Brightness: "); Serial.print(pwmValue);
  Serial.print(" | Manual Override: "); Serial.println(manualOverride ? "ON" : "OFF");
  
  delay(10);
}

Challenges

• • Balancing Automatic and Manual Modes:
    Getting the right balance between automatic brightness adjustments and a satisfying manual override was a fun challenge. I had to fine-tune the mapping of LDR readings to PWM values until the LED’s response felt right in different lighting conditions.

  • Debugging with Serial Monitor:
    Utilizing the Serial Monitor was incredibly useful. Every time something wasn’t working as expected, I added more Serial prints to understand what was happening.

Physical Computing:
It was really interesting to see all the different forms that physical computing pieces can take. The examples given, despite only being a small glimpse into the genre, cover a whole bunch of mediums and correspondingly provide entirely new experiences. In order to do so, they each have to take into account the physical and digital components for both input and output, and figure out how to blend them all together into one working whole. What stood out to me the most was all the little tricks used to make sense of intuitive human motions such as hand movements, as well as the variations of ways to do so. That particular point was also echoed in the introduction, where it mentioned that the same idea can be produced in varying ways. Hopefully as the semester progresses, my own pieces will similarly become more complex and interactive.

Interactive Art:
After the first half of this class and the resulting midterm project, I can definitely identify with what the reading is getting at. The previous readings on different aspects of design come into play once again, albeit with more emphasis on the physical aspect this time around. The listening aspect builds on that and turns the creation process into a more iterative version of itself to presumably beneficial effect. I liked the comparison to telling an actor how to act versus giving them the tools to perform their craft, which naturally leads into the next analogy of the piece being a performance involving the audience. Going forward I’d like to keep this perspective in mind, and endeavour to provide a more comprehensive experience in my work.

Physical Computing’s Greatest hits and misses

Reading this text really made me think differently about what it means to design interfaces, especially ones that don’t rely on screens or traditional controls. The idea that your own hands can act as a cursor, like in the Atlas Gloves project, really struck me. It’s such a nice twist on a familiar interaction we use on a daily basis, and it made me realize that innovation can come from reimagining how we use our bodies every day to communicate with technology. Oftentimes, innovation is synonymous to me with inventing entirely new tools, but this showed me that you can use simple materials like a couple of LEDs, gloves, and a webcam and still end up with something cool and interactive.

What also stood out to me was how these projects prioritize experience and embodiment. The Atlas Gloves weren’t just a technical experiment, but rather about movement, spatial awareness, and making the virtual world feel physically accessible. That made me realize that physical computing is as much about how people feel when they use something as it is about how it works. Whether it’s navigating Google Earth with a wave of your hand or playing a theremin-style instrument with motion, there’s a strong emotional and sensory layer involved. That really inspired me to think about my own projects in this class not just as tools or tasks, but as ways to spark connection and curiosity in the people who use them. As a side note, it also really reminded me of kinect sensors on Xbox where you can bowl by doing the motion of bowling or play table tennis my pretending to hold a paddle and smacking.

Making Interactive Art: Set the Stage, Then Shut Up and Listen

Reading Tom Igoe’s article “Making Interactive Art: Set the Stage, Then Shut Up and Listen” made me reconsider the role of an artist in interactive installations. I used to believe that providing detailed explanations would help audiences connect with my work, but Igoe suggests that over-explaining can limit personal interpretation. He emphasizes creating a context that encourages participants to explore and derive their own meanings, comparing this approach to a director guiding actors without dictating their every move. This perspective highlights the importance of designing experiences that invite engagement and allow for a range of responses, which makes me reflect on how I can craft environments that speak for themselves and foster genuine interaction. It’s also a true testament to how self-explanatory what you create is for people. Like our midterm projects or assignments, we often have to direct our classmates on how to use the controls because we didn’t make it completely obvious. It’s easy to forget that not everyone knows how it was made and how it is supposed to work. Seeing how others try to make it work and whether they get it right rather than explaining makes the interaction much better.

Google Drive Link: https://drive.google.com/file/d/1_hd31ynpr4AzkeD99QR3nakPaNJlEiRF/view?usp=sharing

My idea for this assignment was to have a light that would automatically turn on when it was dark in the room while the other light could be manually turned on. Kind of like a smart light vs a regular light switch light. To do this is use the photoresistor to get the values of the brightness in the room and coded the arduino such that under a certain threshold, the light would automatically turn on.

The circuit diagram looked like this:

The code for it can be seen here:

const int LED_PIN = 9;
const int LIGHT_THRESHOLD = 500;
// the setup routine runs once when you press reset:
void setup() {
  // initialize serial communication at 9600 bits per second:
  pinMode(LED_PIN, OUTPUT);
  Serial.begin(9600);
}

// the loop routine runs over and over again forever:
void loop() {
  // read the input on analog pin
  int sensorValue = analogRead(A2);
  // print out the value you read:
  Serial.println(sensorValue);
  delay(1);  // delay in between reads for stability
  if (sensorValue < LIGHT_THRESHOLD) { //codes the light to turn on when brightness is low
    digitalWrite(LED_PIN, HIGH);
  } else {
    digitalWrite(LED_PIN, LOW);
  }
  delay(100);
}

Overall, it wasn’t too difficult. I just struggled a bit with getting the wires in the correct places and accidentally blew a light because the resistor wasn’t plugged in all the way. It’s tricky dealing with so many wires on the board, I wish it could look more streamlined.

 

Concept:

For my Arduino Sensor LED Control, I wanted to combine analog and digital inputs in a single interactive system. A potentiometer (analog) not only drives the brightness of one LED but also “unlocks” a digital LED toggle. Only when the potentiometer is turned into a specific window (300–700) does pressing the pushbutton flip the digital LED on or off. To make the fade more dramatic, the potentiometer value is squared before mapping to PWM, so small turns near the high end feel much brighter.

Setup:

• Potentiometer: Reads an analog value (0–1023) on pin A0. Its value controls the analog LED’s brightness and gates the button’s functionality.
• Pushbutton: Connected to pin 2 with a pull-down resistor. When pressed, it toggles the digital LED only if the potentiometer value is between 300 and 700.
• Digital LED: On pin 10, turns on or off based on the button toggle (when enabled by the potentiometer).
• Analog LED: On PWM pin 9, its brightness is set by a squared mapping of the potentiometer value, creating a non-linear fade effect (brighter at higher values).

Creative Element: The requirement for the potentiometer to be in a specific range to enable the button adds an interactive challenge, making the system feel like a “lock” that must be “unlocked” by dialing in the right potentiometer position.

Arduino Code:

const int potPin = A0;        // Potentiometer analog input
const int buttonPin = 2;      // Pushbutton digital input
const int digitalLedPin = 10;  // Digital LED output
const int analogLedPin = 9;  // Analog LED (PWM) output

int buttonState = 0;          // Current button state
int lastButtonState = 0;      // Previous button state
bool ledState = false;        // Digital LED state (on/off)

void setup() {
  pinMode(buttonPin, INPUT);
  pinMode(digitalLedPin, OUTPUT);
  pinMode(analogLedPin, OUTPUT);
}

void loop() {
  // Read sensors
  int potValue = analogRead(potPin);  // 0–1023
  buttonState = digitalRead(buttonPin);

  // Control digital LED
  if (buttonState == HIGH && lastButtonState == LOW) {
    // Button pressed, check if potValue is in range (300–700)
    if (potValue >= 300 && potValue <= 700) {
      ledState = !ledState;  // Toggle LED state
      digitalWrite(digitalLedPin, ledState ? HIGH : LOW);
    }
  }
  lastButtonState = buttonState;  // Update button state

  // Control analog LED (non-linear brightness)
  float normalized = potValue / 1023.0;  // Normalize to 0–1
  int brightness = 255 * (normalized * normalized);  // Square for non-linear effect
  analogWrite(analogLedPin, brightness);
}

Schematic:

Demo:

Challenges

• Range calibration: Finding the sweet-spot (300–700) took a few tests—too narrow and the button felt unresponsive; too wide and the “lock” felt trivial.

• Button bounce: Without debouncing, sometimes a single press registered multiple toggles. I ended up adding a small delay in code to ignore rapid changes.

• Non-linear fade tweaking: The square mapping made lower values almost invisible. I had to play with exponent and mapping constants so the fade curve felt smooth.

 

Reading 1

Reading Tom Igoe’s blog post on the “greatest hits (and misses)” of physical computing really made me reflect on how approachable and endlessly creative this field can be. As someone who’s still growing my understanding of interactive technology, I found his message super reassuring, especially the idea that it’s okay to revisit classic project ideas like light-sensitive instruments or pressure-sensitive floors. Instead of feeling like I’m copying someone else’s work, Igoe made me realize that there’s value in reinterpreting those familiar ideas in new, personal ways. It reminded me that creativity isn’t always about inventing something completely new—it’s also about seeing old ideas through a different lens.

Igoe’s emphasis on how machines don’t understand intention—only action- was what caught my attention the most. It got me thinking about how important it is to really consider how people will interact with what I make. It’s not just about the cool factor of the tech; it’s about how people feel when they use it. Igoe’s point about designing systems that are intuitive and human-centered stuck with me. It encouraged me to start paying more attention to how people move, gesture, and react in everyday life—because that’s where meaningful interaction begins.

Reading 2

In “Making Interactive Art: Set the Stage, Then Shut Up and Listen,” Tom Igoe presents a thoughtful perspective on the role of the artist in interactive work. He emphasizes that the artist’s job is to create an environment that invites engagement, not to dictate how people should respond. This idea stood out because it shifts the focus from controlling the audience’s experience to trusting them to find their own way through the piece. Igoe’s comparison to theater directing, where the director sets the scene but lets the actors interpret it, captures this idea well. It reminded me that successful interaction often comes from subtle suggestions, not detailed instructions.

What I found especially valuable was Igoe’s insistence on listening, observing how people interact with a piece instead of trying to steer them. It’s a reminder that interactive art is a two-way conversation, and part of the creative process is stepping back and allowing space for surprise and interpretation. This approach encourages more open-ended, personal experiences for the audience.