Week 10 | Assignment

Concept
For this assignment, Ghadir and I created a mini piano keyboard using Arduino with 7 notes (C, D, E, F, G, A, B). Each note is played using a button, and the pitch can be changed using the potentiometer. The switch allows the sound to shift higher or stay at the original pitch depending on its position.

Each button corresponds to a specific frequency for one note. When you press a button, the Arduino sends a signal to the buzzer to play that frequency. The blue switch works as a pitch modifier. This combination creates a mini keyboard where you can experiment with simple melodies and play around with tone changes.

Schematic

Digital Arduino

Demo Video

Reflection
To improve the project, we could’ve add more interactivity by including volume control, perhaps using a potentiometer. Another idea is to incorporate visual feedback, like an LED or an LCD display, to indicate which note or pitch is being played. These improvements would make the keyboard more versatile and closer to a real musical instrument.

Code

// Pin definitions for each button
const int buttonPins[7] = {2, 3, 4, 5, 6, 7, 8}; // Buttons for notes C, D, E, F, G, A, B
const int buzzerPin = 9;                         // Pin for the buzzer
const int potentiometerPin = A0;                 // Pin for the potentiometer

// Frequencies for notes C, D, E, F, G, A, B
const int noteFrequencies[7] = {261, 294, 329, 349, 392, 440, 493};

void setup() {
  // Set each button pin as input
  for (int i = 0; i < 7; i++) {
    pinMode(buttonPins[i], INPUT);
  }
  pinMode(buzzerPin, OUTPUT);  // Set the buzzer pin as output
  Serial.begin(9600);          // Start serial monitor for debugging
}

void loop() {
  int potValue = analogRead(potentiometerPin);    // Read the potentiometer value (0-1023)
  
  // Map potentiometer value to a "volume" level (duration)
  int volumeLevel = map(potValue, 0, 1023, 10, 200); // Larger value = longer tone duration

  bool notePlayed = false;      // Track if a note is being played

  // Check each button to see if it's pressed
  for (int i = 0; i < 7; i++) {
    if (digitalRead(buttonPins[i]) == HIGH) {
      int frequency = noteFrequencies[i];      // Get the note's frequency

      // Play the note with duration based on potentiometer setting
      tone(buzzerPin, frequency);
      delay(volumeLevel);
      noTone(buzzerPin);
      
      notePlayed = true;                       // Indicate that a note is played
      break;                                   // Play only one note at a time
    }
  }

  // Stop the tone if no button is pressed
  if (!notePlayed) {
    noTone(buzzerPin);
  }

  delay(10);                                   // Small delay for stability
}

 

Assignment 8 – Piano

Concept
For this assignment, Fatima and I created a mini piano keyboard using Arduino with 7 notes (C, D, E, F, G, A, B). Each note is played using a button, and the pitch can be changed using the potentiometer. The switch allows the sound to shift higher or stay at the original pitch depending on its position.

Each button corresponds to a specific frequency for one note. When you press a button, the Arduino sends a signal to the buzzer to play that frequency. The blue switch works as a pitch modifier. This combination creates a mini keyboard where you can experiment with simple melodies and play around with tone changes.

Schematic

Digital Arduino

Demo Video

Reflection
To improve the project, we could’ve add more interactivity by including volume control, perhaps using a potentiometer. Another idea is to incorporate visual feedback, like an LED or an LCD display, to indicate which note or pitch is being played. These improvements would make the keyboard more versatile and closer to a real musical instrument.

Git hub

Week 10 Assignment: instrument

Concept

For this assignment, we were inspired by the toy pianos that we’ve all played with at least a few times as children. These toys were often quite limited, as they only had enough space to accommodate the keys for a single octave. We decided to create a miniature piano that could play the notes from C to A, with a knob that can be turned to change octaves.

Setup and Code

We set up a row of buttons that play a note when pressed, a potentiometer that changes the octave, and a switch that switches the notes to their respective sharp notes.

We created arrays that store the frequencies of the natural notes across seven octaves, doing the same for the sharp notes. The range of the potentiometer is mapped to a range of 0-6 and determines which octave the notes will be played in. When the switch is low, natural notes are played, and vice versa.

To prevent the notes from continuously playing, the noTone() function stops the buzzer playing any sound when no button is pressed.

Full code on Github

if (buttonState7 == LOW && buttonState6 == LOW && buttonState5 == LOW && 

    buttonState4 == LOW && buttonState3 == LOW && buttonState2 == LOW) {

  noTone(8);  // Stop any tone on pin 8

}

 

Open photoDemo

Vid link

Reflection

Overall, this group project was a success as we managed to recreate our inspiration using Arduino. We were really satisfied with how we made sure to implement the natural notes as well as sharp notes in our project. A few struggles we faced was that the wires and resistors were really crowded on our small breadboards, making it a little difficult to reach the buttons. Ideally, we would want to get bigger breadboards in the future so that there would be more room for interacting with the product. Additionally, the bread board was just a little too small for us to add the 7th natural note, so we could only fit 6, as we’re missing a B note. 

In the future, we would like to add two different colored led lights that switch on and off along with the natural or sharp notes. This way, it would help users know if they are currently playing natural or sharp notes, as not everyone is familiar with musical notes in that sense. 

 

Week 10 reading reflection

A Brief rant on the Future of Interactive Design 

In this reading, the author voices his frustrations with current and future visions of input devices being centered on touch screens, or as he calls it Picture Under Glass. I aggree with the authors frustrations with ordinary objects moving to become less tactile and moving to resemble touch screens. For example, many new induction stoves utilize touch capacitive buttons, which become quite unresponsive when you’re cooking and have greasy fingers. Much of the “innovations” for the future now are fixing problems that were non-existent to begin with. As the author said, our hands and fingers can do much more than just touch and swipe, which is the only thin a touch screen allows us to do. What we need to innovate is a way to utilize more than this basic motion, to create technology that is able to make use off the various other features that our hands are capable of.

Responses: 

The author acknowledges that no solution is possible with the current state of our technology, however, what he is trying to tell us is that our hands are capable of much more, and instead of “improving” everything by transitioning to touch screen interfaces, we need to aim to keep the tactile sensations that we are much used to and are much more used to.

 

Assignment 7: How fairies play the piano

Concept:

For this assignment, my partner Fasya and I designed a musical instrument that merges digital and analog elements to create an interactive, light-based piano. Our idea centers around a glowing wand that functions as a control interface. When moved over the keys, the wand activates notes from the C major scale (C, D, E, F, and G) like magic, and the brightness of its glow determines the octave. We integrated a potentiometer to adjust brightness, allowing users to easily shift the octave up or down. Additionally, we added a switch to toggle the instrument off, which prevents accidental note activation—particularly useful to avoid unintended sounds from ambient light sources like flashlights.

Highlight:

To bring our vision to life, we used five photoresistors to detect light from the wand and mapped each sensor’s range to specific notes (C, D, E, F, and G) and their octave scales. By setting sensor thresholds from a default minimum to a maximum value that a flashlight might produce, we could dynamically adjust the octave based on the brightness the photoresistor detects. Essentially, the brighter the wand, the higher the octave, allowing for an expressive range in tone.

For the wand itself, we created a purple glow using a tricolored LED, giving the instrument an ethereal fairy-like visual quality. A potentiometer is attached to the LED to control brightness, making it easy for users to adjust octaves on the fly. The setup includes separate circuits for the keyboard and wand, creating flexibility for future enhancements, such as adding multiple wands for collaborative play.

Keyboard Code:

#include "pitches.h"
bool buttonState = false;
// Define the piezo buzzer pin
const int buzzerPin = 8;

// Define frequencies for each note across multiple octaves
const int fNotes[] = {NOTE_F4, NOTE_F5, NOTE_F6, NOTE_F7};  // Octaves of A
const int gNotes[] = {NOTE_G4, NOTE_G5, NOTE_G6, NOTE_G7};  // Octaves of B
const int cNotes[] = {NOTE_C4, NOTE_C5, NOTE_C6, NOTE_C7};  // Octaves of C
const int dNotes[] = {NOTE_D4, NOTE_D5, NOTE_D6, NOTE_D7};  // Octaves of D
const int eNotes[] = {NOTE_E4, NOTE_E5, NOTE_E6, NOTE_E7};  // Octaves of E

void setup() {
  // Initialize serial communication at 9600 bps for debugging
  Serial.begin(9600);
  pinMode(7,INPUT);
}

void loop() {
  // Array to store sensor values
  int sensorValues[5];
  int switchValue = digitalRead(7);
  if (switchValue == HIGH){
      buttonState = true;
  }

 
  // Read each sensor value and store in the array
  sensorValues[0] = analogRead(A3);  // f note
  sensorValues[1] = analogRead(A4);  // g note
  sensorValues[2] = analogRead(A0);  // C note
  sensorValues[3] = analogRead(A1);  // D note
  sensorValues[4] = analogRead(A2);  // E note

  // Play a note based on each sensor value
  for (int i = 0; i < 5; i++) {
    int note;
    if (sensorValues[i] < 850 || !buttonState) {
      // Stop any sound if the sensor value is below 900
      noTone(buzzerPin);
      continue;
    } else {
      // Map the sensor value (900 to 1100) to an index (0 to 3) for each note array
      int noteIndex = map(sensorValues[i], 850, 1100, 0, 3);

      // Assign the note based on the sensor index
      switch(i) {
        case 0: note = fNotes[noteIndex]; break;
        case 1: note = gNotes[noteIndex]; break;
        case 2: note = cNotes[noteIndex]; break;
        case 3: note = dNotes[noteIndex]; break;
        case 4: note = eNotes[noteIndex]; break;
      }
      
      // Play the mapped frequency on the piezo buzzer
      tone(buzzerPin, note);
    }
    
    // Delay to control the speed of tone change
    delay(100);
  }
}

Wand Code:

// *Interfacing RGB LED with Arduino 
// * Author: Osama Ahmed 

//Defining  variable and the GPIO pin on Arduino
int redPin= 9;
int greenPin = 10;
int  bluePin = 11;
int potPin = A2;
int sensorVal = 0;
double brightness = 0;

void setup() {
  Serial.begin(9600);
  //Defining the pins as OUTPUT
  pinMode(redPin,  OUTPUT);              
  pinMode(greenPin, OUTPUT);
  pinMode(bluePin, OUTPUT);
}
void  loop() {
  sensorVal = analogRead(potPin);
  brightness = (double)sensorVal / 1023;
  Serial.println(brightness);
  
  setColor(170, 0, 255, brightness); // Purple Color
  // delay(1000);
}
void setColor(int redValue, int greenValue,  int blueValue, double brightValue) {
  analogWrite(redPin, (double) redValue * brightValue);
  analogWrite(greenPin,  (double) greenValue  * brightValue);
  analogWrite(bluePin, (double) blueValue  * brightValue);
}

Demonstration:

Keyboard Circuit Schematic
Wand Circuit Schematic

 

WEEK 10 RADIO (Amna and Noura)

CONCEPT:

While brainstorming project ideas with Amna, we thought about how a radio works and decided it would be fun to make a simple version. Our goal was to create an Arduino “radio” that lets you switch between different songs, similar to tuning a real radio. We used a knob as the channel switch, allowing us to choose between three different songs that we got from Github and the exercises we did in class. Each channel has its own song, and turning the knob instantly switches to the next song, giving it a real radio-like feel. We also added a button that acts as a power switch to turn the radio on and off. This way, pressing the button starts the radio, and pressing it again turns it off. We even added a feature so that any song stops playing immediately when the channel changes, so you don’t have to wait for a song to finish before switching to a new one.

HIGHIGHT:

The part Amna and I are most proud of is getting the button to work smoothly with the debounce feature. At first, the button would trigger multiple times with a single press, turning the radio on and off too quickly. By adding a debounce function, we made sure the button only registers one press at a time, making it much more reliable. A former student in IM (Shereena) helped us understand how debounce works and guided us in fixing this issue, explaining how it makes the button’s response stable and accurate.

Here’s a snippet of the debounce code we used:

// Variables for debounce
int buttonState; // Current state of the button
int lastButtonState = LOW; // Previous state of the button
unsigned long lastDebounceTime = 0; // Last time the button state changed
unsigned long debounceDelay = 50; // Debounce time in milliseconds

void loop() {
int reading = digitalRead(buttonPin);

// Check if the button state has changed
if (reading != lastButtonState) {
lastDebounceTime = millis(); // Reset debounce timer
}

// If enough time has passed, check if the button is pressed
if ((millis() - lastDebounceTime) > de
bounceDelay) {
if (reading != buttonState) {
buttonState = reading;
if (buttonState == HIGH) {
radioState = !radioState; // Toggle radio on/off
}
}
}

lastButtonState = reading;
}

 

This debounce function prevents accidental multiple triggers, making the button interaction smoother. We’re also proud of how the radio switches songs instantly when we turn the knob, making it feel real.

REFLECTION:

Working on this project with Noura was a nice experience, as we got to share our thoughts and class experience by working together. One of our main struggles was making the button work without triggering multiple times, which led us to use debounce for stability. While adding Debounce solved the problem, in the future, we’d like to explore other ways to troubleshoot and fix issues like this without relying on debugging alone.

For future improvements, we’d like to add more interactive features, such as volume control with an additional knob and possibly a small speaker for clearer sound. We could also include more “channels” with various songs or sound effects, giving users a richer experience. Another idea is to add an LED indicator that lights up when the radio is on and changes brightness with volume, making the design even more engaging. These changes would make our project more realistic for a radio and enhance.

How it works:

CODE:

https://github.com/nouraalhosani/Intro-to-IM/blob/426c7d58639035c7822a4508f2e62dab34db0695/Radio.ino

WEEK 10 – Radio

CONCEPT:

While brainstorming project ideas with Noura, we thought about how a radio works and decided it would be fun to make a simple version ourselves. Our goal was to create an Arduino “radio” that lets you switch between different songs, similar to tuning a real radio. We used a knob as the channel switch, allowing us to choose between three different songs that we got from Github and the exercises we did in class. Each channel has its own song, and turning the knob instantly switches to the next song, giving it a real radio-like feel. We also added a button that acts as a power switch to turn the radio on and off. This way, pressing the button starts the radio, and pressing it again turns it off. We even added a feature so that any song stops playing immediately when the channel changes, so you don’t have to wait for a song to finish before switching to a new one.

HOW IT WORKS:

SETUP:

 

HIGHIGHT:

The part Noura and I are most proud of is getting the button to work smoothly with the debounce feature. At first, the button would trigger multiple times with a single press, turning the radio on and off too quickly. By adding a debounce function, we made sure the button only registers one press at a time, making it much more reliable. A former student in IM (Shereena) helped us understand how debounce works and guided us in fixing this issue, explaining how it makes the button’s response stable and accurate.

Here’s a snippet of the debounce code we used:

// Variables for debounce
int buttonState;          // Current state of the button
int lastButtonState = LOW; // Previous state of the button
unsigned long lastDebounceTime = 0; // Last time the button state changed
unsigned long debounceDelay = 50;   // Debounce time in milliseconds

void loop() {
  int reading = digitalRead(buttonPin);

  // Check if the button state has changed
  if (reading != lastButtonState) {
    lastDebounceTime = millis();  // Reset debounce timer
  }

  // If enough time has passed, check if the button is pressed
  if ((millis() - lastDebounceTime) > debounceDelay) {
    if (reading != buttonState) {
      buttonState = reading;
      if (buttonState == HIGH) {
        radioState = !radioState;  // Toggle radio on/off
      }
    }
  }

  lastButtonState = reading;
}

This debounce function prevents accidental multiple triggers, making the button interaction smoother. We’re also proud of how the radio switches songs instantly when we turn the knob, making it feel real.

REFLECTION:

Working on this project with Noura was a nice experience, as we got to share our thoughts and class experience by working together. One of our main struggles was making the button work without triggering multiple times, which led us to use debounce for stability. While adding Debounce solved the problem, in the future, we’d like to explore other ways to troubleshoot and fix issues like this without relying on debugging alone.

For future improvements, we’d like to add more interactive features, such as volume control with an additional knob and possibly a small speaker for clearer sound. We could also include more “channels” with various songs or sound effects, giving users a richer experience. Another idea is to add an LED indicator that lights up when the radio is on and changes brightness with volume, making the design even more engaging. These changes would make our project more realistic for a radio and enhance.

CODE:

https://github.com/nouraalhosani/Intro-to-IM/blob/426c7d58639035c7822a4508f2e62dab34db0695/Radio.ino

 

WEEK 10 READING

This rant on “Pictures Under Glass” made me realize how strange it is that we’re so comfortable reducing our interactions to something as flat and lifeless as a touchscreen. We have our hands (the most useful body part), and yet we limit them to swiping and tapping like we’re settling for the simplest form of interaction possible. It’s almost like we’re choosing numbness over true engagement, relying on a screen instead of exploring the world with our hands.

To me, this flat, touch-only future ignores a huge part of being human. While reading, I thought about how much richer experiences are when you can actually feel things. Imagine the difference between seeing a piece of pottery on a screen versus shaping it yourself. It’s a completely immersive experience that teaches you in ways a screen never could. If tech continues down this path, I feel like we’re just training ourselves to be satisfied with empty interactions that don’t ask much of us.

Furthermore, I think relying so heavily on screens is what’s making us lazy; it feels like we’re choosing convenience over truly connecting with the world. Screens limit how we explore and interact, reducing everything to a simple swipe or tap. Technology should be enhancing our natural abilities, not shrinking them down to one basic motion.

Moreover, the push for brain-computer interfaces is even worse. It takes away the real, physical experiences that make life interesting. Instead of cutting out physical interaction, I believe tech should work with our bodies, such as the Wii console or the VR, helping us connect in more meaningful, hands-on ways.

Reading Reflection – Week #10

The idea of developing immersive technology that goes beyond the limits of the 2D screen has been concerning me for a while already, so I got very involved into the topic of the rant by Victor Bret. Interactive design was an ambiguous term back in 2011, when the text was published, and remains often misunderstood now. How can we call “pictures under glass” truly interactive if we do not engage with them physically?

Haptics are one way to push the boundaries of human-computer interaction further. When our fingers get some sort of response, even a slight vibration, it makes our experience with gadgets more engaging on a cognitive level. Here is an example from my life: my phone is always in silent mode, so when I type something, I do not hear the artificial sound of keys clicking. At some point I stopped understanding whether I am actually typing – so I turned on the “haptic response” feature. This makes the keys vibrate slightly every time I press on them, which creates a more realistic experience of using a physical keyboard.

Nonetheless, I agree with Bret that interactivity can be pushed even beyond haptics. At the same time, it is still difficult to come up with a clear solution, if there is one. Reading Bret’s ideas almost 15 years later was interesting, considering the latest inventions in AI which, to some extent, contradict with his points about the use of voice – turns out it can be used to generate something beyond linguistics.

READING WEEK – 10

Reading the rant, it made me realize how much we’ve settled for touchscreens as our main way of interacting with technology. Sure, they’re easy to use, but I think they’re holding us back from something much richer. Kids today are glued to screens, swiping and tapping all day, and I feel like it’s making them “finger-blind.”. They’re losing the chance to understand the world through real touch. Instead of feeling textures and weights, they’re just seeing everything through glass. In my opinion, that’s robbing them of a huge part of learning and growing.

And it’s not just kids. Even for adults, I feel like we’re missing out on deeper connections with tech. Take virtual reality games. Everyone loves the visuals, but games like Beat Saber feel empty to me without any sense of touch or resistance. It’s a hollow experience, one that relies only on what we see, not what we feel. I think this disconnect leaves us with flashy visuals but no real engagement.

Beat Saber – VR

In addition, I also think that the obsession with brain-computer interfaces is just as disappointing. Sure, it sounds futuristic, but I think it’s actually a step back. The idea of controlling things with thoughts alone ignores the importance of our bodies. We’re already sitting at screens too much, and this just pushes us deeper into that immobility. I believe technology should encourage movement and real interaction, not trap us in a still, disconnected state.

“Pictures Under Glass” sums up the issue perfectly. It’s like we’re numbing one of our most powerful senses for convenience. When I pick up a book or a glass, my hands get all kinds of feedback from weight, texture, and balance. But with a screen? Nothing. Even something as simple as making a sandwich taps into a level of interaction that a screen can’t touch. In my view, designers need to stop treating screens as the final answer and start creating tech that actually respects our bodies’ abilities.