For this assignment, I tried to create two lighting options using one analog sensor, one digital sensor, and two LEDs. One option acts like a simple lamp that turns on and off, while the other acts more like a mood lamp whose brightness can be adjusted. I used the potentiometer as the analog input and the button as the digital input. I used the yellow LED as the on and off indicator for the system, and I used the blue LED as the mood light. I liked this idea because it was simple, but it still made the difference between digital and analog input and output very clear.

Week9

The way it works is that the button turns the system on and off, which the yellow LED shows. When the system is on, the blue LED changes brightness based on the potentiometer. That means the yellow LED works in a digital way, because it is either fully on or fully off, while the blue LED works in an analog way because its brightness changes gradually. In that sense, the project feels like choosing between two lighting options: a basic on and off lamp, and a second lamp that can be adjusted.

Arduino File on GitHub

For the code, I used one variable to store the button state, another to store the last button state, and a variable called systemOn to remember whether the lamp is on or off. I used INPUT_PULLUP for the button, so the button normally reads HIGH and becomes LOW when pressed. Then I used an if statement to check if the button had just been pressed, and if it had, I changed the system state. After that, I used analogRead() to get the potentiometer value, and map() to convert that value from 0 to 1023 into a brightness range of 0 to 255. That brightness value is then sent to the blue LED using analogWrite().

The part of the code I am most proud of is where the potentiometer reading gets turned into brightness for the blue LED, while the button still controls the overall on and off state of the lamp. I like this part because it made the project feel more intentional. The blue LED does not just turn on randomly. It only works when the system is on, and then its brightness changes based on the potentiometer. That made the whole lamp feel more organized and easier to understand.

if (buttonState == LOW && lastButtonState == HIGH) {
   if (systemOn == 0) {
     systemOn = 1;
   } else {
     systemOn = 0;
   }
   delay(200);  
 }
 lastButtonState = buttonState;
 

 int sensorValue = analogRead(A0);
 
 
 if (systemOn == 1) {
  
   digitalWrite(yellowLed, HIGH);
   int brightness = map(sensorValue, 0, 1023, 0, 255);
   analogWrite(blueLed, brightness);
 } else {
   digitalWrite(yellowLed, LOW);
   analogWrite(blueLed, 0);
 }

I am proud of this part because it brings the whole project together. The button controls the digital state of the system, and the potentiometer controls the analog brightness of the blue LED. I think this made the assignment much easier to understand in a practical way, because it clearly separated the role of the digital input and the analog input.

One thing I liked about this assignment is that it made the difference clear. The yellow LED is either fully on or fully off, while the blue LED can be dim, medium, or bright depending on the potentiometer. If I had more time, I would probably make the mood lamp more visually expressive, maybe by adding another color.

 

Design Meets Disability

The first thing I thought of when reading the text is when Chinese jewelry brand YVMIN designed prosthetics for the Chinese model Xiao Yang. They were honestly like no other prosthetic I had ever seen attached below are only some of the designs:

This text coupled with my memory of the model made me think about how inclusivity, design, and functionality should be combined in a product. A lot of the times people with disabilities face problems with self-esteem and self-image, so incorporating incredible designs to me feels like an important aspect of building any product. Especially when looking at how glasses are seen as fashionable items; I even remember hearing people tell me about how they would fake not being able to read letters at the doctor’s office to get glasses.

Nonetheless, I feel that a product without all three elements is incomplete. A lot of the times you see certain elements incorporated into a product for the sake of aesthetics that just end up making using the product much more difficult. Or sometimes the design just looks ugly altogether.

This reading was really eye-opening and made me reflect on how I should incorporate all three elements into my designs to make them most effiicient and accessible.

Also yes I forgot to mention, including fashion with products made for disabilities is brilliant whether its in glasses, hearing aids, prosthetics, or bionics.

Design Meets Disability

This was an interesting read, especially the idea of discretion in disability design. I honestly realized I never really questioned it before, I just kind of assumed that making things invisible or less noticeable was automatically better, but the reading made me realize it is actually much more about culture and how people feel about themselves. The example of the Eames leg splint was interesting to me because I did not expect something medical to be described as a beautiful design. The idea that a medical object could actually lead to iconic furniture made me rethink the direction of influence in design. It does not just go from mainstream to disability, but the other way around, too.

The idea of discretion vs fashion also really changed how I think about assistive devices. I have definitely grown up seeing and hearing things like hearing aids or prosthetics as something you need to hide, so the idea that invisibility might actually reinforce shame really stuck with me. The comparison with the glasses made a lot of sense because I have never thought of glasses as medical, I sometimes see them as normal or even stylish. Which makes me wonder why other devices have not gone through the same shift yet.

I also found the discussion about simplicity really relatable, especially the iPod example. I have definitely experienced how too many features in a product can actually make it harder to use. The example of simple radios for people with dementia made me think about how inclusion is not just physical, but also about how easily something can be understood without stress. Overall, this reading has me thinking about how much design depends on who is involved in the process, especially considering it needs input from mainstream designers and artists because disability design does not have to be separate or special. It can actually shape what good design looks like for everyone.

Here are pics and videos:

 

Video link if not working:

https://drive.google.com/file/d/1pQPYnyUyf5OOBwbfCVHiDrsOvqDn_P3d/view?usp=sharing

Here is my GitHub link:
https://github.com/farahshaer/Intro-to-IM/blob/4ff1ee52b33d4edf72a1f905fc3d014cd8dfadb6/sketch_apr14a.ino 

Overall concept

So for this project, I built an interactive music system that plays two different songs (Jennifer’s Body by Ken Carson and Die with a Smile by Bruno Mars), and you can control the pitch of the melodies. I included a buzzer for the sound output, a button to switch between the songs, a potentiometer to change the pitch, and an LED that visually blinks along with the music. The main idea was to create something interactive where you can actually affect the sound while it is playing.

Code Highlight

One part of my code that I am particularly proud of is the if statements that switch between the two melodies and make the LED blink:

//mode 0 (melody 1)
  if (mode == 0) {

    int size1 = 15;                                      //number of notes in melody 1
    int noteDuration = 1000 / noteDurations1[thisNote];  //converts note type into time in milliseconds
    int finalPitch = melody1[thisNote] + pitch;          //combines the meoldy note and the knob turning (can adjust the note using the potentiometer)
    tone(buzzer, finalPitch, noteDuration);              //plays sound on buzzer
    digitalWrite(led, HIGH);                             //turns led on while the note is playing
    delay(noteDuration);                                 //waits for note to finish
    digitalWrite(led, LOW);                              //turns the led off between the notes and for blinking effect
    delay(noteDuration * 0.3);                           //short pause between the notes to make the melody clearer
    noTone(buzzer);                                      //stops sound before next note
    thisNote++;                                          //moves to next note in the melody
    if (thisNote >= size1) thisNote = 0;                 //if at the end of the melody go back to the start (loop song)
  }


  if (mode == 1) {
    int size2 = 23;                                      //number of notes in melody 2
    int noteDuration = 1000 / noteDurations2[thisNote];  //converts note into time (mill sec)
    int finalPitch = melody2[thisNote] + pitch;          //applys the pitch shift from the potentmeter
    tone(buzzer, finalPitch, noteDuration);              //plays sound
    digitalWrite(led, HIGH);                             //turns led on during the sound
    delay(noteDuration);                                 //wait for note
    digitalWrite(led, LOW);                              //led off
    delay(noteDuration * 0.3);                           //pause between notes
    noTone(buzzer);                                      //stops sound

    thisNote++;                           //go to the next note when done
    if (thisNote >= size2) thisNote = 0;  //loop back to start when song ends
  }
}

This is the core of my project because instead of playing an entire song at once, it processes one note at a time, which allows for real-time interaction through the button and the potentiometer. The code selects the current note, modifies pitch with the sensor input, and then outputs the sound plus the LED, while moving to the next state.

Reflection/future work

I cannot lie, I had trouble with the code, but the wiring was straightforward once I understood how each component connected to the Arduino. The buzzer is connected to digital pin 8, and outputs sound using the tone() function. The LED is connected to digital pin 9 with a resistor, and it provides visual feedback by blinking in sync with each note. The button is connected using INPUT_PULLUP, meaning it reads HIGH when not pressed and LOW when pressed, which required me to wire one side to ground so the logic would work correctly. The potentiometer is connected to analog pin A0, with one side connected to 5V, the other to ground, and the middle pin sending a variable signal that controls pitch in the code.

For the code, I used a variable called thisNote, which stores the current position in the melody array. Instead of using a for loop to play the entire song at once, the code plays one note per loop cycle, which allows for constant checking for input changes while the music is playing. At first, I used for loops, and it just was not working. The Arduino got stuck inside the loop, the button presses were ignored until the song finished, and the potentiometer did not update in real time, so switching to thisNote, it made the program run one note at a time inside the loop. So the Arduino can check the button constantly, and the song can change and pitch in real time.

I also had a problem with the button logic, because at first I wrote if (buttonState == LOW) and it caused it to continuously trigger while the button was held down, which made the song behave unpredictably. So I used chatgpt to debug and I learned to use lastButtonState with buttonState so the code only detects a transition from high to low (single press instead of holding), and because I used input_pullup, I also had to adjust my thinking since high is not pressed and low was pressed so it was confusing at first because it is the opposite of what I expected.

Overall, I learned that structure matters just as much as logic, especially when dealing with real-time input and output, because small details like button states and loop structure completely change how responsive the system feels. For future improvements, I would add more songs or more modes, and more LEDs or patterns to visualize the rhythm more creatively, and probably replace delay with millis for smoother control.

Here is my schematic:

References:

(I mainly used the lecture slides), but I also used these websites for a better understanding.
https://github.com/hibit-dev/buzzer/blob/e1442497e7c56cee0d5efe73304bdb922b3ab907/src/songs/ken_carson_jennifers_body/ken_carson_jennifers_body.ino

https://github.com/hibit-dev/buzzer/blob/e1442497e7c56cee0d5efe73304bdb922b3ab907/src/songs/die_with_a_smile/die_with_a_smile.ino

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

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

Concept

The requirement of creating a musical instrument with electrical components made me think of the Theremin, but I didn’t want to copy the logic comletely. So I dicided to use the ultrasonic distance sensor to imitate the change by hand movement. I also wanted to make the instrument a beat generater, because beats can be manipulated in their pitch, tempo and even rhythm pattern. This allows much more variation. So the ultimate design concept was to have the ultrasonic distance sensor acts as a pitch controller, where the player can move thir hand away or closer to the sensor to control pitch, the potentialmeter controls the tempo, and the toggle switch allows alternation between rythm patterns. I was responsible for the code while Mariam was responsible for the wiring and schematics.

Video Demo

Video was made by Mariam Barakat

Schematics

Schematics also made by Mariam Barakat

Code Snippet

https://github.com/JingyiChen-jc12771/Intro-to-IM/blob/e15f6f3478d8937ba91372ab2eed7e34a691b2b8/Week_10_assignment/Week_10_assignment.ino

int scale[]={NOTE_C4, NOTE_D4, NOTE_E4, NOTE_G4, NOTE_A4, 
  NOTE_C5, NOTE_D5, NOTE_E5, NOTE_G5, NOTE_A5};

The code shown above is the note array. It is used so not every single sound in the range of the distance to pitch mapping is used. This removes the more irritating pitches and leaves the actual notes, just to make the instrument sound better.

long duration,cm;
int switchState = digitalRead(switchPin);
//measuring chunk for the ultrasonic distance sensor
digitalWrite(distPin,LOW);
delayMicroseconds(2);
digitalWrite(distPin, HIGH);
delayMicroseconds(10);
digitalWrite(distPin, LOW);
//records the time between output of ultrasound and echo. 10000 sets a limit in case there is not close enought object, it prevents the program from stopping completely by setting cm to 0.
duration=pulseIn(echoPin,HIGH,10000);
//uses the convertion function to convert the time to distance
cm = microsecondsToCentimeters(duration);
//if the distance of object is further than 50cm away treat it as 50cm, this limits the range of distance.
if(cm==0||cm>50){cm=50;}
//map the distance to the array of notes, 2 is the reliable begining measurement of the sensor
int noteIndex = map(cm, 2, 50, 0, numNotes - 1);
int currentNote=scale[noteIndex];

//the function to convert time to distance, 10000 time would result in 0cm
long microsecondsToCentimeters(long microseconds) {
  return microseconds / 29 / 2;
}

This is the chunk where the distance sensor is activated and does its measuring, and the measurements are mapped to the note array. The code for initiating ultrasound release and receiving echos are referenced from a tutorial for 4 pin ultrasonic sensors on the Arduino project hub and the Arduino IDE Ping example for 3 pin ultrasonic sensors. The code tells the sensor to be quiet for 2 microseconds, emit ultrasound for 10 microseconds, and then stops so the echo can be listened for. Then the time it took for the echo to get back is assigned to the duration variable, which is converted to distance in cm used the function i found in the Arduino Ping example. The distancer is then mapped to the indexes of the note array, so distance would corresopond to note.

if (currentMillis - startMillis >= tempo) {
    startMillis = currentMillis; 
    beatStep++;
    //the beat generation
    //switch controls two states, one where the beats play at a steady tone
    if(switchState==HIGH){
      tone(buzzerPin,currentNote,50);
      //In the other state the beat is deeper at even beats and lighter at odd beats
    }else{if(beatStep%2==0){
      tone(buzzerPin,100,50);
    }else{
      tone(buzzerPin,currentNote,50);
    }
  }
}

This code snippet is the part that times the beats and controls the button alternation between the two rythm styles. The timer uses the same logic as the timer we have done in p5. Time passed is recorded in millis. the time the last beat was played was assigned to “startMillis”, and current time is “currentMillis”. When time interval between the two millis exceed the tempo, the next beat is played.

One of the switch state plays a steady tone, where the beat is played at the pitch defined by the redings of the distance sensor all the time. The other state plays an alternating pattern.  if(beatStep%2==0) results in even beats playing at a hard coded 100Hz, and odd beats at the distance influenced pitch. This can also be modified. The even beat can be made half the frequency, double the frequency, or pitch desired.

Reflection

The biggest challenge was with the timer. Initially we tried to use delay as we did in all our previou codes and the whole unit would freeze and not work at all. Thinking back to our P5 experience we figured using a background timer of millis would allow the unit to keep running between beats. The end result was good and the beats flowed smoothly. Something we could have done better might be to expand the array so the pitches are not that limited. Something else that would have been fun but a bit less feasible is adding more push buttons, and make the pitch or overall style change when the button is pushed, like a groove box. But that would work better if the output was not limited to a piezo speaker. That would allowe a wider variety of sounds and might even create some DJ effects.

 

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

• • https://pyserial.readthedocs.io/en/latest/
  • https://docs.arduino.cc/built-in-examples/sensors/Ping/
  • Google Gemini — used for wiring guidance

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.

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:

• Code on Github

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.

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.

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:

MariamMhara

Demonstration:

Mariam

Mhara

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.

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.