Reading Response #? (feat. not one, but TWO articles from Tom Igoe)

Physical Computing’s Greatest Hits (and Misses)

Reading this was humbling, to say the least. I expected to find a list with cool projects I could maybe borrow and try to make for myself, but what I got instead was more like a map of every “original” idea a beginner is likely to have. Theremins, gloves, floor pads, things you yell at, fields of grass, the endless lure of blinking LEDs, mirrors that are digital to easily wow every person with a limited understanding of technology (and even those who have more than a limited understanding of technology), things to hug. Everything has already been charted out and accounted for. I do like that the author mentions that some students, upon realizing their idea has been done before, just give up. which he thinks is exactly the wrong reaction. His take is that these themes keep coming back because they leave room for genuine variation, and the interesting part is never the concept itself but what a particular person does with it.

Something that stuck with me was how unflinching he is about each theme’s weaknesses. A theremin is fun, yeah, but congrats on waving your hand, I guess. What does it mean? What now? Video mirrors are beautiful and also happen to offer almost zero structured interaction (hah, screen savers). Meditation helpers can’t read minds. Remote hugs don’t actually feel like hugs. He isn’t dunking on any of these ideas, but is rather saying that the baseline, easy version of each one is surface-level, and real design work is whatever comes AFTER you’ve built that surface and started asking harder questions.

That reframing is how my thought process usually works. Rather than creating something and wondering only if it works, I also like to ask myself if the gesture I’m asking for is actually worth asking for. Why use a button instead of a pull, or a wave or a shout? What does this action feel like in my body, and does it match what I want the piece to be about? Ultimately, despite us all learning the same coding language and basics of Arduino, we all end up with different projects because of how we individually come up with ideas. As long as you know the basics, you can bend the rules after as much as you want.

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

This reading opens up with a pretty blunt rule, “Don’t interpret your own work,” and then spends the rest of it explaining why this rule exists. To Igoe, interactive art isn’t something you deliver to an audience, but rather, is a conversation you’re starting with them. If you stand next to your piece telling people what each element represents and how they should feel about it, you’ve already pre-written their experience, and at that point, there’s no reason for them to actually engage with what you made. (For this reason, I like to read museum labels for paintings AFTER I’ve engaged with the piece, so I can experience it twice. I found that it doesn’t usually work the other way… thank you, anchoring bias!)

The analogy that made this click was directing an actor. You can’t tell a performer what to feel and expect anything real to come out. Rather, you arrange the space, place the props, suggest intentions, and let them figure out the emotions themselves. An interactive piece works the same way: put a handle on what you want touched, make unapproachable things unapproachable, drop hints towards what you want discovered, and then (with all due respect), back off. The catch, though, is you need to genuinely trust the audience, and trust that what you built is legible enough to speak for itself (scary!) for it to work. Igoe’s point is also that these reactions are also data, not failures to argue with.

An interactive piece is never really “done”. The object you build is just a stage, and the audience finishes the work every time they walk up to it, slightly different each time. That’s a pretty different mental model from traditional art, and I suspect it’s one of those things that doesn’t fully sink in until you’ve actually watched strangers misuse something you made.

And…

Back-to-back, these two readings feel like they have similar arguments made from two angles. The first is about what to make, while the second is how to present what you made. Both converge on a single idea, that you kind of… aren’t the point (sorry). The gesture is the point, and the person performing it is the point. We’re really putting the interaction (between our performer and the gestures in between to communicate with the work) in interactive media. Hahaha. Sorry.

Week 10 – Production and Reading Reflection Megan

Production: LED Lights Memory Game

Concept

The concept of my project was to create a memory-based LED game inspired by the small game we watched in class. In that example, a light would turn on and the first person to press the button on their side would win. I found that idea very engaging, so I wanted to build something similar but with a stronger focus on memory and sequence. While looking for ideas, I came across the concept of a “Simon Says” style memory game, which immediately reminded me of a toy I used to play with as a child, similar to a Pop It memory game with lights and patterns. This connection made the idea more personal and interesting to develop, so I decided to create a game where the Arduino generates a sequence of LED lights and the player must repeat it correctly using buttons.

Process

To build this project, I started by learning the basic components separately. I watched several tutorials by Paul McWhorter, which helped me understand more things on how LEDs and buttons can work, as well as how to structure Arduino code using functions, loops, and conditionals. I also explored the Arduino documentation to better understand how different functions work and how Arduino programming compares to tools like p5.js. The good thing is that both use similar logical structures, which made it easier for me to understand the code. I programmed the Arduino to generate a random sequence, display it using LEDs, and then check the user’s input through buttons. I also added a startup LED test to verify that the circuit was working correctly before the game begins.

// LED MEMORY GAME


// PIN SETUP

// LED pins
int redLED = 12;
int yellowLED = 9;
int greenLED = 6;
int blueLED = 3;

// Button pins
int redButton = 11;
int yellowButton = 8;
int greenButton = 5;
int blueButton = 2;


// GAME VARIABLES
int sequence[10];   // stores up to 10 steps
int level = 0;      // current level


// ==============================
// SETUP 
// ==============================
void setup() {

  // Set LED pins as OUTPUT
  pinMode(redLED, OUTPUT);
  pinMode(yellowLED, OUTPUT);
  pinMode(greenLED, OUTPUT);
  pinMode(blueLED, OUTPUT);

  // Set button pins as INPUT (with internal pull-up)
  pinMode(redButton, INPUT_PULLUP);
  pinMode(yellowButton, INPUT_PULLUP);
  pinMode(greenButton, INPUT_PULLUP);
  pinMode(blueButton, INPUT_PULLUP);

  // Start random generator
  randomSeed(analogRead(0));


  // ==============================
  // STARTUP LED TEST
  // ==============================

  // Turn on each LED one by one
  digitalWrite(redLED, HIGH);
  delay(300);
  digitalWrite(redLED, LOW);

  digitalWrite(yellowLED, HIGH);
  delay(300);
  digitalWrite(yellowLED, LOW);

  digitalWrite(greenLED, HIGH);
  delay(300);
  digitalWrite(greenLED, LOW);

  digitalWrite(blueLED, HIGH);
  delay(300);
  digitalWrite(blueLED, LOW);

  delay(500); // small pause before game starts
}


// ==============================
// MAIN LOOP 
// ==============================
void loop() {

  addStep();        // add new random color
  showSequence();   // show LED sequence

  bool correct = checkPlayer(); // check user input

  if (correct == false) {
    gameOver();     // if wrong → game over
    resetGame();    // restart
  }

  delay(1000);
}


// ==============================
// FUNCTIONS
// ==============================


// Add a new random step
void addStep() {
  sequence[level] = random(0, 4);
  level++;
}


// Show the sequence using LEDs
void showSequence() {

  for (int i = 0; i < level; i++) {

    turnOnLED(sequence[i]);
    delay(500);

    turnOffAll();
    delay(250);
  }
}


// Turn on the correct LED
void turnOnLED(int number) {

  if (number == 0) digitalWrite(redLED, HIGH);
  if (number == 1) digitalWrite(yellowLED, HIGH);
  if (number == 2) digitalWrite(greenLED, HIGH);
  if (number == 3) digitalWrite(blueLED, HIGH);
}


// Turn off all LEDs
void turnOffAll() {

  digitalWrite(redLED, LOW);
  digitalWrite(yellowLED, LOW);
  digitalWrite(greenLED, LOW);
  digitalWrite(blueLED, LOW);
}


// Check player input
bool checkPlayer() {

  for (int i = 0; i < level; i++) {

    int buttonPressed = waitForButton();

    // Show feedback
    turnOnLED(buttonPressed);
    delay(300);
    turnOffAll();

    // Check correctness
    if (buttonPressed != sequence[i]) {
      return false;
    }
  }

  return true;
}


// Wait for button press
int waitForButton() {

  while (true) {

    if (digitalRead(redButton) == LOW) {
      delay(200); // debounce
      return 0;
    }

    if (digitalRead(yellowButton) == LOW) {
      delay(200);
      return 1;
    }

    if (digitalRead(greenButton) == LOW) {
      delay(200);
      return 2;
    }

    if (digitalRead(blueButton) == LOW) {
      delay(200);
      return 3;
    }
  }
}


// Game over animation
void gameOver() {

  for (int i = 0; i < 3; i++) {

    digitalWrite(redLED, HIGH);
    digitalWrite(yellowLED, HIGH);
    digitalWrite(greenLED, HIGH);
    digitalWrite(blueLED, HIGH);

    delay(300);

    turnOffAll();

    delay(300);
  }
}


// Reset game
void resetGame() {
  level = 0;
}

Difficulties

One of the main difficulties I encountered was related to the physical design of the circuit, especially the buttons. It was challenging to make the buttons clearly visible and easy to press during gameplay. At times, the wires made the setup look cluttered and slightly uncomfortable to use. To improve this, I adjusted the layout of the breadboard and repositioned it to the left side instead of the right, which made the buttons more accessible. However, I still believe the design could be improved. A possible solution would be to use shorter wires, since the ones included in the kit are relatively long and make the circuit less organized.

Thing that I’m Proud Of

One aspect of the project that I am particularly proud of is the feedback system when the player loses. I programmed all the LEDs to blink simultaneously several times, creating a clear and satisfying visual indication that the game is over. This small detail enhances the user experience and makes the game feel more complete and interactive.

Reflection Overall

Overall, I found this project very enjoyable and rewarding. It allowed me to combine creativity with technical skills and to better understand how hardware and software interact. I especially liked how I could take a simple idea and gradually build it into a functional game. If I were to improve this project in the future, I would like to add sound effects, such as tones that play when each LED lights up, to make the experience more immersive. Although I have not yet implemented this feature, it is something I would like to explore next. This project helped me gain confidence in working with Arduino and problem-solving in both coding and physical design.

PHOTO OF PHYSICAL CIRCUIT

PHOTO OF SCHEMATIC

Reading Reflections

Making Interactive Art

Reading this text me rethink what art even is, especially interactive art, because I feel like I’ve always thought of art as something where the artist is trying to say something very specific, and the audience is supposed to understand that meaning. But here it’s kind of the opposite. It’s saying that if you control too much, if you explain too much, you’re actually limiting the experience. And I find that really interesting but also a bit uncomfortable, because it means you’re giving up control over your own work. Like, you create something, but then people might completely misunderstand it, or interact with it in a way you didn’t expect, and that’s supposed to be part of it. I think what stood out to me the most is this idea that the artwork is not the final product, but more like the beginning of a conversation, and the audience kind of finishes it. At the same time, I feel a bit conflicted, because I wonder if that means the artist’s intention doesn’t matter as much anymore, or if it just becomes too vague. But I do like the idea that interaction is more real when it’s not forced, when people figure things out on their own. It makes the experience more personal instead of just following instructions. So I think the main thing I take from this is that good interactive art is not about telling people what to think, but about creating a space where they can think for themselves, even if that means losing some control over what your work becomes.

Physical Computing’s Greatest Hits (and misses)

This article made me realize something that I hadn’t really thought about before, which is how much creativity is not about doing something completely new, but about how you reinterpret things that already exist. At first, I kind of agreed with that instinct of “if it’s already been done, it’s not original,” but reading this made me see that that idea is actually very limiting. The author shows how the same types of projects keep coming back, like gloves or sensors or interactive spaces, but what changes is how people give meaning to them. And I think that’s the part that stood out to me the most, because it’s not really about the technology itself, it’s about the interaction and what it makes people feel or do. At the same time, I also feel a bit conflicted, because some of these projects sound very repetitive or even a bit shallow, like things that look cool but don’t really have depth. So it made me question where the line is between something that is genuinely creative and something that is just visually interesting. I think overall the article is kind of saying that originality doesn’t come from the idea itself, but from the intention behind it, but I’m not sure if I fully agree, because I still feel like at some point things can become too repetitive. But I do like the idea that you shouldn’t immediately discard something just because it’s been done before, because that mindset probably stops a lot of good ideas before they even start.

 

Week 9: Reading Response

Emotion and Design: Attractive Things Work Better

The reading starts off with the author’s personal teapot collection and notes their unique qualities: one is functionally absurd, one is ugly yet charming, and one is elegantly engineered for the stages of tea brewing. He uses these very objects to back up his claim that usability need not to be in conflict, and that in fact, things that feel good to use and look at actually perform better in our minds because of the emotional state they put us in, and a beautiful product can help a user work through minor problems that the ugly (but functional) counterpart might not. I do agree with his point on prioritizing usability alone can lead to designs that work but feel sterile, and this reminds me of the function over aesthetics mindset that reinforced in architecture, where function almost overshadows how spaces feel for the consumer. However, while I think his argument fits everyday products well, I don’t think it mirrors the same way with how architecture operates under far greater constraints like structure, material, and safety, where poor functional decisions have serious consequences and it is, from what I can see, a context in which aesthetics can’t come first, though an architectural structure can be beautiful, it ultimately has to serve its purpose of being a safe and functional space to the user.

Her Code Got Humans on the Moon

The article follows mathematician Margaret Hamilton who took a programming job at MIT as something temporary while her husband finished law school, and ended up accidentally building the foundation of software engineering while helping land humans on the moon. There came a situation when her daughter crashed the simulator by triggering a program that no astronaut was ever supposed to activate mid flight and although she flagged it as a real issue and wanted to a kind of debugging code to prevent it, NASA pushed back and claimed that astronauts were too well trained for that. Months later, it happened. I think that kind of overconfidence in human perfection is something a lot of institutions fall into, and it actually reminded me of the Titanic. The ship was considered so structurally sound that the people in charge genuinely claimed it as the “unsinkable”, and that certainty is what made them careless about the lifeboats, the speed, and the warnings. I think both cases show the same thing, which is that when you convince yourself something will never happen, you stop preparing for it, and that is exactly when it does. I truly respected Hamilton for making sure, she stayed prepared and her team was ready to fix it when it did go wrong.

Assignment 10: The Switch, The Dial and The Guesser

“Turning on the light is easy if you know where the switch is” – Colin Wilson

Concept:

Finally we have reached the Arduino era of the class. So to start out, we were tasked to make a analog switch and a digital switch to turn on two LEDs in a digital and analog fashion. But as well, to add a bit of spice to it. Now being honest it took me some time to get my footing with Arduino as this is my first time using and tinkering with it. But I’ve managed to make something at least a bit fun. I’ve been fond of escape rooms and locks, and I thought, what if I make it so depending on where you twist the lock, the LED will shine.

Sketch:

Digital Circuit:

How it’s made:

In terms of designing, the Blue LED is a simple circuit, featuring a resistor set at 220 olms, and wires connecting it to the Ground and Power. The key thing added is a simple switch that the user can interact with to turn the LED on or off.

However the Red LED has instead a potentiometer. I chose it as it’s use as a dial is going to be key to solving what random value the LED is in. Basically, I have a random function that generates a random value between the lowest and highest value of the potentiometer. Then we read the current value of the potentiometer which uses the function analogRead(). And finally we use a simple if else statement to check if the value is the same, and if so the LED will shine. I’ve added a buffer just so it’s not too difficult to guess.

Highlighted bit of Code I’m proud of:

Outside of the regular struggles with making the digital design, I struggled figuring it out why the random value wasn’t truly random. It was confusing as I assumed somehow it was reading the value of the potentiometer and using that variable as a constant. But that wasn’t the case, so I was a bit dumbfounded as the result variable in the code below isn’t tied to anything.

I did a bit of googling and found out that if I use the random function then it will give me a random number. But, it will repeat everytime, practically serving as a constant, and that wasn’t helpful everytime I would start the simulation. So apparently, you are supposed to add a seed to a code to make it unique and it must be on a unconnected pin as it picks up different static which determines the randomness. Really interesting honestly, but a pain to figure that quirk out.

randomSeed(analogRead(A0));
result = random(0, 1022);

Reflection

Overall I’m pleased with my tinkering for now. I feel like just making the digital design on tinkercad was an experience in itself but also trying to find some sort of creative spin for the LEDs. I think potentially I could add more to it, but I’m fine this being a simple game and hopefully as the weeks go, we can try out different things.

Full Code:

int inputPin = 0;
int outputPin = 2;
int result = 0;

void setup(){
  
  Serial.begin(9600);
  
  randomSeed(analogRead(A0));
  result = random(0, 1022);
  
  pinMode(outputPin, OUTPUT);
  
}
  
void loop(){
 
  int potentialVal = analogRead(0);
  Serial.println(potentialVal);
  Serial.println(result);

  if (potentialVal >= result - 20 && potentialVal <= result + 20){
    digitalWrite(outputPin, HIGH);
  }
  else{
  	digitalWrite(outputPin, LOW);
  }
  
}

 

Week 10 — Musical Instrument

Mariam B and Jenny

1. Repository

Repository

2. Overview

This project is an interactive electronic musical instrument. An ultrasonic distance sensor acts as a pitch controller — the player moves their hand closer or further away to select notes from a pentatonic scale. A potentiometer controls the tempo of the beat. A toggle switch changes between two musical modes: a steady melodic mode where every beat plays the note selected by the player’s hand, and a drum-style alternating mode where deep and light tones trade off rhythmically. All sound is produced through a piezo buzzer.

3. Concept

The concept was inspired by the Theremin — a classical electronic instrument played without physical contact, where the performer’s hand position in the air controls the pitch of the sound. Rather than pressing discrete keys to trigger notes, the player sculpts sound by moving their hand through the air above the ultrasonic sensor. This creates a continuous, expressive range of input that feels intuitive and physical at the same time. The toggle switch gives the instrument two distinct personalities — one melodic and one percussive — while the potentiometer lets the player set the energy of the performance by controlling how fast the beat moves.

    • Note on AI assistance: The wiring configuration for this project was determined with the help of Google Gemini. The circuit concept was described to Gemini and it provided wiring instructions for the components.
4. Process and Methods
    • The ultrasonic distance sensor fires a 10-microsecond pulse and measures how long the echo takes to return. A helper function microsecondsToCentimeters() converts that time into a distance in centimeters. The distance is then mapped to an index in the scale[] array using map(), so each position of the hand corresponds to a specific note.
    • The scale[] array uses note definitions from a pitches.h file and is limited to a two-octave pentatonic scale — C, D, E, G, A across octaves 4 and 5. This removes dissonant half-steps so the instrument always sounds in key regardless of where the hand is placed.
    • The potentiometer is read using analogRead and mapped to a time interval between 150 and 800 milliseconds, which controls how frequently the beat fires.
    • A non-blocking timer using millis() handles beat timing instead of delay(). This keeps the Arduino continuously reading the sensors between beats so the instrument feels responsive and live. A beatStep counter increments on every beat and is used by the alternating mode to separate even and odd beats.
    • The toggle switch selects between the two musical modes and uses INPUT_PULLUP so no external resistor is needed.
5. Technical Details
    • The pitches.h file defines note names as frequency constants, allowing the scale array to be written in readable musical notation rather than raw numbers:
// ── MUSICAL SCALE ──
// A two-octave pentatonic scale (C, D, E, G, A across octaves 4 and 5)
int scale[] = {NOTE_C4, NOTE_D4, NOTE_E4, NOTE_G4, NOTE_A4,
               NOTE_C5, NOTE_D5, NOTE_E5, NOTE_G5, NOTE_A5};
int numNotes = 10;
    • unsigned long is used for the timer variables because the millis() counter grows very quickly and would overflow a standard int (maximum 32,767) after only about 32 seconds:
unsigned long startMillis = 0;
unsigned long currentMillis = millis();
    • The distance sensor trigger sequence follows the standard HC-SR04 pattern — a brief LOW to clear the pin, a 10-microsecond HIGH pulse to fire the sensor, then LOW again to listen:
// ── ULTRASONIC SENSOR TRIGGER SEQUENCE ──
// Pull the trigger pin LOW briefly to ensure a clean starting state
digitalWrite(distPin, LOW);
delayMicroseconds(2);
// Send a 10-microsecond HIGH pulse to fire the ultrasonic burst
digitalWrite(distPin, HIGH);
delayMicroseconds(10);
// Pull LOW again — the sensor is now listening for the echo
digitalWrite(distPin, LOW);

// Measure how long the echo takes to return, in microseconds.
// The 10000 timeout prevents the program from freezing if no object is close enough to reflect the pulse — it returns 0 instead.
duration = pulseIn(echoPin, HIGH, 10000);
    • The distance is mapped starting from 2cm rather than 0 because the HC-SR04 has a physical blind spot below approximately 2 centimetres where readings are unreliable. The upper limit of 50cm keeps the performance zone compact and ergonomic:
int noteIndex = map(cm, 2, 50, 0, numNotes - 1);
    • The alternating drum mode uses the modulo operator on beatStep to separate even and odd beats, assigning a fixed deep tone of 100Hz to even beats as a kick drum and the hand-controlled note to odd beats as a snare:
if (beatStep % 2 == 0) {
  tone(buzzerPin, 100, 50);
} else {
  tone(buzzerPin, currentNote, 50);
}
6. Reflection

This project pushed us to think about musical interaction as much as electronics. The biggest technical challenge was replacing delay() with the millis() timer — understanding why the Arduino had to keep running between beats, rather than pausing, took some time but made the instrument feel genuinely alive and responsive in a way that a delay-based version couldn’t. The decision to use a pentatonic scale rather than mapping the full chromatic range was the single biggest improvement to how the instrument sounds; removing the dissonant notes made even accidental hand movements musical. The Theremin inspiration also shaped how the wiring was approached — describing the concept to Gemini and using its wiring instructions as a reference helped bridge the gap between the interaction idea and the physical circuit. If we were to extend this, we could add a second switch to select between different scales, a visual indicator showing the active mode, and potentially an LCD display to show the current tempo and note being played.

7. Resources

Week 10 – Creative Reading Response

Physical Computing’s Greatest hits and misses

I really enjoyed going through the different themes of physical computing in this article. I felt that I got a lot of inspiration and ideas about possible project ideas, and the explanations provided for each concept really simplified how implementing this idea in practice would look like. Looking through these examples felt like when I would look through past student’s projects on this WordPress. And I’ve also felt that everytime I see an idea that’s been done, it feels like I can’t do that idea anymore either. However, as the author pointed it out, it’s always nice to re-imagine ideas in new contexts, think of new interactions, and as a lot of us did for our midterm projects, link it back to our identity and cultures.

Some themes especially stuck out to me from this article, and I hope to be able to implement them in some way in my work in the future. First, Floor Pads! I love it when a coding project goes way beyond the screen or the usual hardware of wires and buttons. Especially when something is more prominent and unusual, it definitely captures more attention. And something like Floor Pads where there’s movement and a lot of viewer interaction involved can be especially fun. Likewise, Body-as-cursor and Hand-as-cursor are two other themes that stuck out to me for similar reasons. Finally, Things You Yell At was another fun theme, and something I’ve seen a lot at previous IM Showcases. I feel like another common aspect among these themes is that there is no learning curve to understand how it works, you kind of just experiment with it till you get it, usually it’s pretty straightforward.

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

This article made some great points, throughout this class, we’ve spoken a lot about interactive art, what makes it interactive and how to guide users through these interactions. I really appreciated the points it made about allowing your viewers to experiment with the art, rather than force them into the interactions you’ve planned out, allowing them to discover it themselves can be more fun. As the author states, an important part of interactive art is to listen. I think it can be eye-opening to see how viewers look at your art. Especially as most artists spend hours and hours just looking at their work, editing every little detail, and creating everything from scratch, it can be hard to zoom out and see the bigger picture and experience the art through fresh eyes. Hence why it’s important to see how others interact with your work, take it as feedback, maybe just by watching how others interact, you can get new ideas and make edits to your work.

Week 10 — Reading Response

Victor’s “Pictures Under Glass” critique is most compelling not as a takedown of touchscreens specifically, but as a diagnosis of a failure of imagination — the industry confused accessible with good, and then mistook good for visionary. The tool definition he anchors everything to (amplifying human capabilities, not just addressing needs) is doing a lot of work, and it mostly earns it. The sandwich analogy is a little theatrical, but the underlying point lands: we have genuinely extraordinary hands, and sliding a finger on flat glass uses almost none of what makes them extraordinary. The shoelace example is sharper — close your eyes and you can still do it, which is exactly what good tool design should exploit, not eliminate.

What’s interesting is that Victor isn’t really against touchscreens. He’s against treating them as a destination rather than a waypoint. The Kodak analogy in the responses piece clarifies this well: color film wasn’t inevitable, it required people deciding that black-and-white was missing something and doing the research. His concern is that without the rant — without the explicit articulation that something is missing — nobody funds the research. That’s a reasonable fear, and it gives the piece a purpose beyond the polemic.

The responses page is where the argument gets more nuanced and also more interesting. The voice section is the strongest part: his distinction between oracle tasks (ask and receive) and understanding tasks (explore and manipulate) cuts to something real about how knowledge works. You can’t skim a possibility space with your voice. You can’t point at a region of a graph with a command. That’s not a limitation of NLP, it’s a limitation of the modality for that kind of cognition. The explorable explanations he gestures at are a better argument for his position than anything in the rant itself.

The weakest section is the brain interfaces response, which slides from a reasonable point about body-computer mismatch into a somewhat alarmist vision of immobile humans that feels grafted on. And the “my child uses the iPad” rebuttal — channeling all interaction through a single finger is like restricting all literature to Dr. Seuss — is rhetorically satisfying but probably too cute. Accessibility and expressive richness aren’t actually as opposed as the analogy implies; the question is whether you optimize one at the permanent expense of the other. Victor would say yes, that’s exactly what we’re doing. That’s the argument worth sitting with, and it’s one the responses page never quite resolves — which, to his credit, he seems to know.

Week 10 – Musical Instrument

Concept

For this week’s assignment, we decided to create a make-shift piano using the DIY aluminum foil compression button we used in previous assignments. The piano only plays one song; each time you press one of the piano “keys,” the next note in the sequence plays.

For the analog input, we used a potentiometer to control the pitch/frequency of the notes.

Demo:

Implementation:

We created 3 foil switches, taping one side of each switch to GND and the other to a digital pin. Then, we connected the buzzer and potentiometer.

For the code, we used sound files from the same Github repo we used in class. I used the notes for the song “It’s a Small World.”

On every loop iteration, it reads the state of all three buttons and checks if any of them just transitioned from unpressed to pressed, if a button was HIGH last loop and is LOW now, that counts as a single press.

void loop(){
//...

bool justPressed = (state_yellow == LOW && prev_yellow == HIGH) 
                      || (state_blue == LOW && prev_blue == HIGH) 
                      || (state_red == LOW && prev_red == HIGH);

//...
}

When a press is detected, it looks up the current note’s frequency and duration from two parallel arrays, scales the frequency up or down based on the potentiometer reading, plays it through the buzzer, waits for it to finish, then advances to the next note in the melody. The previous button states are saved at the end of every loop so the next iteration can do the same comparison, ensuring each physical press only ever triggers one note no matter how long you hold it down.

Initially, I had the code so that the note plays every time the button is pressed; however, this was causing the entire melody to continuously play as long as the button is pressed. So, we had to come up with a different way to ensure a note is only played when the button changes from unpressed to pressed.

Due to the way the foils are made, it does appear that only one note is playing when the button is pressed. Sometimes when I press the foil button, the foil may touch from one side by accident, or the wires may move which closes and opens the circuit without my intent. Therefore, the device appears to still be playing multiple notes at once but it eventually pauses.

We had to figure out a way to change the pitch of the notes without completely changing what the note was. Since there is a trend among the notes where if you want to move from a note from higher pitch to a lower or vice versa, the note’s pitch value/frequency would need to either be divided by 2 or multiplied by 2.

For example: standard Do sound = C4; a lower pitch would be C3. The difference between the pitch of the two is that C4 is double C3

For that we mapped the potentiometer’s input values (0, 1023) to (50, 200) and divided by 100, this allows us to shift between notes and their pitches smoothly using the potentiometer.

We multiplied this factor to the original note that would have been played and set the tone to include the multiplied value as the frequency in the tone statement.

void loop(){ 
float pitchMultiplier = map(pot_value, 0, 1023, 50, 200) / 100.0;
}

Reflection:

Reflecting on the issue of the foils touching and playing more notes than I want them to, I thought of a way to fix them using cloth pins. I can attach two foils to the inside of the end you use to open the pin, so when you are opening the pin, the foils touch and it counts as a “press.” I imagine this method to function more smoothly than the sponge compression I built for this assignment because the cloth pin is stable and forces the foils away from each other after every press.

Week 10 Musical Instrument – Deema & Dina

Github Link

https://github.com/da3755-ui/intro-to-im/blob/c068b1ccbdb5f327243be9640104c9f9cde83fe1/IntroToIM_MusicalInstrumentAssignment.ino 

Demo on Deema’s page

Concept

For this week’s assignment, we had to create a musical instrument that incorporates both digital and analog input. The concept we came up with was inspired by the floor piano tiles that play notes when you step on them. So, we built a similar concept where we created tiles that produce musical notes when stepped/pressed on AND we incorporated a potentiometer that changes the pitch of the note depending on how you twist and turn it. 

We created three tiles in total. We built it so that no specific tile is linked to a specific note. Just that when you press any tile, a note plays; and if you step again on any other tile, the next note in the sequence plays.

Schematic 

The Process

First, for the piano tiles, we decided to follow the same logic we used in the invisible switch assignment: foils attached to wires that generate power when they make contact, once that was complete, we moved on to incorporating the analog component. We placed the potentiometer and connected it to an analog pin, a 5V pin, and a GND pin. 

For the code:

In order for the arduino to not translate every single LOW reading from a single step into multiple notes, we included a lastTileState component, where the buzzer will only translate the LOW reading to a note if the previous state of the tile was HIGH. This would prevent the tiles from playing multiple notes in one single press.

We had to figure out a way to change the pitch of the notes without completely changing what the note was. Since there is a trend among the notes where if you want to move from a note from higher pitch to a lower or vice versa, the note’s pitch value/frequency would need to either be divided by 2 or multiplied by 2. 

For example: standard Do sound = C4; a lower pitch would be C3. The difference between the pitch of the two is that C4 is double C3

For that we mapped the potentiometer’s input values (0, 1023) to (50, 200) and divided by 100, this allows us to shift between notes and their pitches smoothly using the potentiometer. 

We multiplied this factor to the original note that would have been played and set the tone to include the multiplied value as the frequency in the tone statement.

Originally I had the pitch and factor as just mapping the potentiometer values to the values of all the notes (31, 4978) so the note that is played would correspond to the values of the potentiometer. But then I realized this would change the notes altogether instead of just changing the pitches of the specific notes I chose, that’s when I used chatgpt and it suggested creating a factor component which is where I got the idea from.

I also initially tried keeping the analog and potentiometer section separate from the digital section of the code, adding a separate tone statement for the pitch and another one for the regular notes, but it caused an error, so I had to resort to figuring out a way to incorporate the pitch and analog section in the same section as the digital input.

I also tried incorporating a step counter within the if statement, but it practically added nothing and was not communicating anything to the code so I just removed it entirely.

Code Snippet

I’m personally proud of this if statement snippet because it helped me solve the problem of when to detect if the tiles were JUST pressed instead of if it’s pressed in general, which helped me avoid many problems. It also helped me to get rid of many variables I tried to include to keep track of the steps and presses.

if (
  (tileOneState==LOW && lastTileOneState==HIGH) ||
  (tileTwoState==LOW && lastTileTwoState==HIGH) ||
  (tileThreeState==LOW && lastTileThreeState==HIGH)
)

 

 

Week 10 Assignment – Partner work Mhara & Mariam

Concept:

In this assignment, we had to create a musical instrument using digital and analog sensors. We used push buttons as our digital sensors and a potentiometer as our analog sensor. We then decided to create a mini piano-like device that plays the four basic piano notes C, D, E, and F, and allows the user to adjust the pitch of these notes. In this project, there are four push buttons, each assigned to one note that only plays when the button is pressed, and a potentiometer that changes the pitch of the notes when it is turned.

Code:

Arduino File on GitHub

Setup:

Mariam’s Setup

Mhara’s Setup

 

Demonstration:

Mhara’s video demo:

Mariam’s video demo:

Digital Circuit:

Schematic:

Process:

In the process of this assignment, we decided to combine four buttons (digital) with one potentiometer (analog) to control a piezo buzzer. Each button plays a different note, and the potentiometer slightly adjusts the pitch so the sound changes depending on how much it’s turned. We worked together on the idea and the wiring, but we divided the coding so each of us focused on one part. Mariam handled the digital part (the buttons and the notes), and Mhara worked on the analog part (the potentiometer and the pitch control). After both parts were working separately, we combined them into one full sketch of code.

We then tested the circuit in Tinkercad to make sure all the wiring and logic of the code were correct. This helped us confirm that the buttons were reading properly and that the potentiometer was giving smooth values. Running it in Tinkercad also made it easier to fix small mistakes before trying it on the physical Arduino board.

At first, the audio wasn’t changing when the potentiometer was turned because the mapping was happening after the tone was already being played, so we rearranged the order of the code and that finally made the pitch respond. After that, the sound became too noisy and robotic, so we added a small adjustment range (90 – 105) to each note to make the pitch change smoother and less harsh.

 

Code Snippets:

While building the project, there were a couple of code snippets that stood out to us because they played an important role in making the instrument work the way we wanted it to. 

tone(buzzerPin, noteC * map(sensorValue, 0, 1023, 90, 105) / 100);

This was the part we were most proud of because it solved the “robotic” and “noisy” sound problem. Instead of letting the potentiometer completely change the note, we used a small adjustment (90-150) to bend the pitch smoothly. And this showed how the digital and analog inputs can work together in one line of code. 

 

Another part of the code is :

pitch = map(sensorValue, 0, 1023, 200, 2000);

This line shows how the analog input (the potentiometer) controls the sound. It takes the raw value from 0-1023 and maps it into a pitch range that the buzzer can actually play. This was important because the potentiometer originally wasn’t affecting the sound at all, and fixing the order of the code made this line finally work the way we wanted it to. 

Areas of Improvement and Reflection:

After completing this assignment, we were able to learn and explore different sensors and sounds. It was easy and smooth to work as a pair, as each person focused on one part and then we combined our work together. As for areas of improvement, we could make the sound of the notes smoother and more musical, since it still sounds slightly robotic, or add more notes to make it closer to a real piano. Another idea is to implement other sensors, such as an ultrasonic sensor, to play different notes or even melodies based on motion or distance. Working with audio and sensors is a fun part of Arduino, and it allows us to create many different ideas for various purposes. Overall, we are satisfied with our final outcome and the entire process of this project.

 

References:

Looked back at Week 10 slides about sound to recap what we learned.

Reviewed specific code concepts using the Arduino documentation:

https://docs.arduino.cc/language-reference/en/functions/math/map/ 

  • How we used it: We used this to convert the potentiometer’s range into a smaller pitch-adjustment range that works smoothly with the buzzer.

https://docs.arduino.cc/language-reference/en/functions/advanced-io/tone/ 

  • How we used it: We used this page to understand how the tone() function works and how to send different frequencies to the buzzer. 

https://docs.arduino.cc/built-in-examples/digital/toneMelody/ 

  • How we used it: We looked at this example to understand how notes from pitches.h are used and how tone() can be combined with different frequencies to create musical sounds.

Ai usage:  Used ChatGPT to help navigate and resolve a major issue where the tones sounded too robotic and noisy. From this, we learned that using the map() function with a smaller range for each note helps create smoother, more controlled pitch changes.