Month: April 2026

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.

Video Demo

https://drive.google.com/file/d/1FMsPLRa6d30ubt3L1F19-kvFab5APs4L/view?usp=drive_link

Schematics

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.