Reading Reflection Week 10

One of the examples I found most interesting in “A Brief Rant on the Future of Interaction Design” was the author’s take on voice, especially when he described a fictional situation in which Monet uses his voice to obtain the painting he wants. It may sound ridiculous but I really do agree and understand his argument, how active exploration is necessary in some cases, and the use of voice doesn’t apply. This challenged my own way of thinking, expanding to something essential that the author may be trying to express, whether consciously or not. This is, some forms of interactive will not apply to some cases, and this is why the designer or programmer must understand what is most relevant and effective for the experience they are making. For example, in an interactive experience designed to be engaged while standing up, it might not be the best idea to make certain responses triggered by having the user go click on something on the laptop every time as well. Allowing the user to focus on a few things at a time will improve their experience and help them understand the relevance of the interactive elements within the main objective of the project

 

Something that caught my attention in Bret Victor’s follow-up article was the neglected factor when it comes to tools that are meant to amplify human capabilities, and how hands play an important role in these. I think I speak for many when I say that we often take the skills of our hands for granted. Cooking, drawing, writing, building, organizing, some of the best activities done both for pleasure or to complete a task are done with our hands. And I agree with the author that there is a unique satisfaction that comes from doing these things with our hands. For example, I do love drawing digitally, as the result of my efforts match my intention to draw realistic yet slightly cartoonish objects, landscapes, and characters. However, this process doesn’t match the precision and delicacy of using a brush and applying paint to a canvas, stroke for stroke.

Despite this, I must disagree with the author on one thing. Even though the connection between what I am doing with my hands and the outcome on a screen might not be as strong as doing with another more tangible medium, this does not mean there is no connection at all. Before technology took over most of our ordinary activities such as writing, I enjoyed writing stories with a pen or pencil on my notebook. However, this process became exhausting whenever I had to erase or cross something, or my fingers started to ache from writing for so long. Now, even though I am staring at a screen instead of brushing my fingers over a piece of paper, and typing over a keyboard instead of using a pen, I still enjoy writing just as much as before, and the action has become more manageable for me.

 

Week 10 – Reading Reflection

Bret Victor’s “A Brief Rant on the Future of Interaction Design” reads less like a complaint and more like a plea for imagination. His frustration with “pictures under glass” isn’t really about touchscreens rather about how easily we mistake convenience for progress. Victor’s argument that our hands are not just pointers but thinking tools is relatable. I’d never thought of a touchscreen as “numb,” but he’s right: sliding a finger across glass is nothing like twisting, folding, or shaping an object. He’s asking designers to respect the body’s intelligence, the millions of years of evolution that made us good at feeling, gripping, and sensing the world. I agree with him almost entirely. What unsettles me is how quickly we’ve accepted numbness as normal. We’ve trained ourselves to think that friction is a flaw when it comes to UX.

The Responses piece adds an interesting layer of humility. Victor doesn’t pretend to have the solution. He admits he was ranting, not designing one. Still, his answers to critics are telling. He pushes back against gimmicks like voice control and “waving your hands in the air,” arguing that real interaction should involve the whole body and the tactile richness of touch. I found myself nodding at his line about computers needing to adapt to our bodies, not the other way around. That’s such a simple reversal, yet it cuts right through decades of design laziness. When he compares touchscreen culture to “restricting all literature to Dr. Seuss’s vocabulary,” it’s funny, but it also nails the deeper loss: we’re settling for tools built for children, not adults.

If there’s one thing I’d question, it’s Victor’s nostalgia for physicality. I agree that touch and movement matter, but I also think the human imagination adapts. The digital world is training new forms of dexterity which are mostly mental than physical. Coding, multitasking, navigating layered interfaces – these, too, are forms of “touch,” just less visible. Maybe the future of interaction design isn’t about replacing glass with holographic clay, but about balancing sensory depth with cognitive range. Victor’s rant reminds me that design should evolve with both the hand and the mind.

Week 10 – Reading Reflection

I think the idea of moving beyond flat screens is important. Victor Bret’s rant from 2011 makes me think about this a lot. He says our hands are amazing tools. I believe he is right. We should use our hands’ full abilities, not just for poking glass. I see a problem with how we use technology today. We call things interactive when they are not. Tapping a picture on a screen is a limited way to interact. I think true interaction should involve more of our senses and our physical body. It should feel like we are handling real things. Bret’s follow-up answers show that some people missed his point. They focused on new screen technology. But I believe his main idea was about our hands. He wanted us to think about touch and grip, not just better displays.

This makes me consider the role of voice commands. Some people think voice is the future. But I think it has limits. Speaking is not always practical or private. Our hands are often faster and more precise. The best future might combine voice, touch, and physical movement. I feel that the real challenge is for designers. They need to imagine tools that use our whole bodies. I believe we need technology that feels less like a window and more like a material. We need to build things we can truly feel and shape with our hands. This is a difficult but exciting goal.

Week 10: Musical Instrument (Ling and Mariam)

Concept

For this assignment, I worked together with Ling to create an instrument using the ultrasonic sensor. He came up with the idea to use the distance sensor, and the way we executed it reminded me of a theremin because there’s no physical contact needed to play the instrument. We also used a red button to turn the instrument on and off, as well as a green button that controls the tempo of the piezo buzzer (based on how many times you click on it in 5 seconds).

Schematic Diagram

 

Code

const int trigPin = 9;  
const int echoPin = 10; 
const int buzzerPin = 8; 
const int buttonPin = 4;  // system ON/OFF button
const int tempoButtonPin = 2;  // tempo setting button

//sensor variables
float duration, distance; 
bool systemOn = false; // system on or off state

// tempo variables
bool tempoSettingActive = false; 
int  tempoPressCount    = 0;   
unsigned long tempoStartTime = 0;
unsigned long tempoInterval  = 500; 

// for edge detection on tempo button (to count presses cleanly)
int lastTempoButtonState = HIGH;

// for edge detection on system button (cleaner)
int lastSystemButtonState = HIGH;


// for controlling when next beep happens
unsigned long lastBeatTime = 0;



void setup() {  
 pinMode(trigPin, OUTPUT);  
 pinMode(echoPin, INPUT);  
 pinMode(buzzerPin, OUTPUT);
 pinMode(buttonPin, INPUT_PULLUP); // system ON/OFF button 
 pinMode(tempoButtonPin, INPUT_PULLUP);  // tempo button 
 Serial.begin(9600);  
}  

void loop() {
  // system on/off state
  int systemButtonState = digitalRead(buttonPin);

  // detects a press: HIGH -> LOW 
  if (systemButtonState == LOW && lastSystemButtonState == HIGH) {
    systemOn = !systemOn;  // Toggle system state

    Serial.print("System is now ");
    Serial.println(systemOn ? "ON" : "OFF");

    delay(200); // basic debounce
  }
  lastSystemButtonState = systemButtonState;
  
  // if system is OFF: make sure buzzer is silent and skip rest
  if (!systemOn) {
    noTone(buzzerPin);
    delay(50);
    return;
  }

  // tempo button code
  int tempoButtonState = digitalRead(tempoButtonPin);

  // detects a press 
  if (tempoButtonState == LOW && lastTempoButtonState == HIGH) {
    if (!tempoSettingActive) {
      
      //first press (starts 5 second capture window)
      tempoSettingActive = true;
      tempoStartTime = millis();
      tempoPressCount = 1;  // Count this first press
      Serial.println("Tempo setting started: press multiple times within 5 seconds.");
    } else {
      // additional presses inside active window (5 secs)
      tempoPressCount++;
    }

    delay(40); // debounce for tempo button
  }
  lastTempoButtonState = tempoButtonState;

  // if we are in tempo mode, check whether 5 seconds passed
  if (tempoSettingActive && (millis() - tempoStartTime >= 5000)) {
    tempoSettingActive = false;

    if (tempoPressCount > 0) {
      // tempo interval = 1000 ms / (number of presses in 5 secs)
      tempoInterval = 1000UL / tempoPressCount;

      // avoids unrealistically fast intervals
      if (tempoInterval < 50) {
        tempoInterval = 50;
      }

      Serial.print("Tempo set: ");
      Serial.print(tempoPressCount);
      Serial.print(" presses in 5s -> interval ");
      Serial.print(tempoInterval);
      Serial.println(" ms between beeps.");
    } else {
      Serial.println("No tempo detected.");
    }
  }
 
  // ultrasonic sensor distance measurement
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);

  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);

  duration = pulseIn(echoPin, HIGH);
  distance = (duration * 0.0343) / 2.0;  // in cm

  Serial.print("Distance: ");
  Serial.println(distance);

  
  //buzzer pitch and tempo
  // checks if distance is valid and in a usable range
  if (distance > 0 && distance < 200) {
    float d = distance;

    // limit distances for stable mapping
    if (d < 5)  d = 5;
    if (d > 50) d = 50;

    // maps distance to frequency (closer = higher pitch)
    int frequency = map((int)d, 5, 50, 2000, 200);

    // uses tempoInterval to define how often we "tick" the sound (creates short beeps at each interval using current frequency)
    unsigned long now = millis();

    if (now - lastBeatTime >= tempoInterval) {
      lastBeatTime = now;

      // plays a short beep (half of the interval duration)
      unsigned long beepDuration = tempoInterval / 2;
if (beepDuration < 20) {
beepDuration = 20;  // minimum hearable blip
 }

tone(buzzerPin, frequency, beepDuration);
}

 } else {
    // if bad/no reading, silence the buzzer between ticks
    noTone(buzzerPin);
  }
  delay(50); //delay to reduce noise

}
Favorite Code
//buzzer pitch and tempo
// checks if distance is valid and in a usable range
if (distance > 0 && distance < 200) {
  float d = distance;

  // limit distances for stable mapping
  if (d < 5)  d = 5;
  if (d > 50) d = 50;

  // maps distance to frequency (closer = higher pitch)
  int frequency = map((int)d, 5, 50, 2000, 200);

This is a pretty simple part of the code, but I loved how the beeping sounds turned out. It’s so satisfying to see how my hand movements directly control the sound, and it made me realize how significant even a small part of the code could be.

The code was completed with assistance from ChatGPT.

Video Demo

Reflection and Future Improvements

Mapping the distance to control the sound was pretty simple. The challenging part was controlling the tempo, we had to figure out the values to divide in order for it to have a clear change in the sound of the piezo buzzer after clicking the green button. Overall, this was a really cool project and I hope to continue to improve and expand my knowledge in physical computing!

Week 10 Production(Ling and Mariam)

Conceptualization

For this week’s assignment, the requirement is to “Make a musical instrument “while using at least one digital sensor (switch), at least one analog sensor (photoresistor, potentiometer, or distance measuring sensor).” I have worked with photoresistor last week, and potentiomter isn’t aesthetic enough for a musical instrument in my view, so I looked into the toolbox and proposed to apply ultrasonic sensor, or in another word, distance measuring sensor. It works perfectly as a tool to measure the distance between the sensor and any solid object in real-time and we were thinking to map this distance to pitches so that whenever people move their hands in front of the sensor, the sound the buzzer make would change accordingly.

After implement this simple step, I was thinking about two problems: first, how could i integrate a switch into this system, and second, is there anyway to alter the tempo, which is another important factor in making music, of the sound the buzzer made. To resolve the first problem, i first decide to add a system on/off switch since it’s just logical to add a switch to control the entire system. To resolve the second problem, I proposed to add a switch to control the tempo of the sound it made since after the first implementation, the buzzer would just make continuous sound and it would be hard to add any tempo element to the instrument.

We decided there could be 2 means to control the tempo:

  1. The switch would record manual interaction with the switch and play the sound precisely how it is manually inputted.
  2. The switch would record how many times people push the button within a 5-second time period(starting from the first push) and calculate the tempo based on 1000ms dividing the times the button is pushed.

We finally decided to go with the second option as it would provide us with a more steady tempo since manual input could be mathematically unstable otherwise.

So the final output(the video demonstration and the schematic) is demonstrated below.

Video Demonstration

Schematic

Code Highlight:

In my opinion, there are two interesting part about this program. First, how the pitch is controlled(a basically mapping program) and secondly, the program to control the tempo(the logic of the tempo-control is listed above).

duration = pulseIn(echoPin, HIGH);
distance = (duration * 0.0343) / 2.0;  // in cm
// Check if distance is valid and in a usable range
  if (distance > 0 && distance < 200) {
    float d = distance;

    // Limit distances for stable mapping
    if (d < 5)  d = 5;
    if (d > 50) d = 50;

    // Map distance to frequency (closer = higher pitch)
    int frequency = map((int)d, 5, 50, 2000, 200);

This code highlights how the pitch is correlated to the distance in programs.

duration = pulseIn(echoPin, HIGH);

This measures how long the echo signal stayed HIGH. This is the time for the sound to travel to the obstacle and back.

distance = (duration * 0.0343) / 2;

The duration(in microseconds) is multiplied by the speed of sound in air (0.0343 cm/µs). It’s divided by 2 because the sound traveled to the object and back, but we only want one-way distance.

// Detect a press (falling edge: HIGH -> LOW)
  if (tempoButtonState == LOW && lastTempoButtonState == HIGH) {
    if (!tempoSettingActive) {
      // First press: start 5-second capture window
      tempoSettingActive = true;
      tempoStartTime = millis();
      tempoPressCount = 1;  // Count this first press
      Serial.println("Tempo setting started: press multiple times within 5 seconds.");
    } else {
      // Additional presses inside active window
      tempoPressCount++;
    }

    delay(40); // debounce for tempo button
  }

This is the tempo controlling program. I think it is very self-explanatory with the comments in the code.

The entire code is completed with assistance from GPT.

Reflection:

For future improvements, i want to work with buzzer that produce better sound than this one, but the working experience with this buzzer is transitive for future works.

 

Week 9: Analog and Digital Sensor

Concept:

For this project, I decided to use one digital sensor and one analog sensor to control two LEDs. For the digital part, I connected a push button to a digital pin to control one LED — pressing the button turns the light on, and releasing it turns it off. For the analog part, I used a potentiometer connected to an analog input to control the brightness of a second LED through an analog output. As I turned the knob, the LED smoothly adjusted its brightness, demonstrating how analog signals can vary continuously instead of just turning on or off. This setup reflects the difference between digital and analog control and how both can work together in an interactive circuit.

Video Demonstration:

https://drive.google.com/file/d/1_urM0vEA__Piz7zGG_TUHDnuhy5QYUgQ/view?usp=drive_link

Circuit Illustration:

Code Highlight:

// Define pin numbers
int ledPin1 = 11;   // LED controlled by potentiometer (analog LED)
int ledPin2 = 2;    // LED controlled by button (digital LED)
int buttonPin = 7;  // push button input

void setup() {
  // Set pin modes
  pinMode(ledPin1, OUTPUT);     // pin 11 used for PWM (brightness control)
  pinMode(ledPin2, OUTPUT);     // pin 2 for digital on/off LED
  pinMode(buttonPin, INPUT);    // button as input (external resistor required)
  
  Serial.begin(9600);           // start serial monitor for debugging
}

void loop() {
  // Read the potentiometer (analog sensor)
  int sensorValue = analogRead(A1);     // reads values from 0–1023
  Serial.println(sensorValue);          // print the reading to serial monitor

  // Control the brightness of LED on pin 11
  // analogWrite expects a range 0–255, so divide by 4 to scale down
  analogWrite(ledPin1, sensorValue / 4);
  delay(30);                            // small delay to stabilize readings

  // Read the push button (digital sensor)
  int buttonState = digitalRead(buttonPin);   // reads HIGH or LOW

  // Control the digital LED based on button state
  if (buttonState == HIGH) {     // if button is pressed (connected to 5V)
    digitalWrite(ledPin2, HIGH); // turn LED on
  }
  else {                         // if button is not pressed (LOW)
    digitalWrite(ledPin2, LOW);  // turn LED off
  }
}

Github Link:

https://github.com/JaydenAkpalu/Intro-to-IM/blob/f43175106ae171c88a5c7db0410a56dc965127af/Week9_AnalogAndDigitalSensor.ino

Reflections & Future Improvements:

Working on this project helped me really understand the difference between digital and analog sensors and how they can control things like LEDs. I saw that a digital sensor, like a push button, only has two states — on or off — which makes it easy to control an LED directly. On the other hand, an analog sensor, like a potentiometer, can give a range of values, letting me gradually adjust the brightness of an LED. It was really satisfying to see how these two types of input behave so differently in a circuit.

If I were to improve the project, I’d try adding more interactive elements. For example, I could use multiple buttons or potentiometers to control more LEDs, or even combine the potentiometer with a light sensor so the LED responds to changes in the environment automatically. I’d also like to experiment with different LED effects, like fading, blinking patterns, or color changes, to make it more dynamic and fun. Overall, this project gave me a better understanding of how simple inputs can be used creatively to make interactive circuits.

Week 10 – A DIY Musical Instrument (The Ultrasonic Air Piano)

Concept:

The idea behind my instrument was to create a hands-free musical device that transforms invisible gestures into sound. My goal was to design something playful yet technical; a device that reacts to both motion and touch. By combining distance and pressure, the instrument invites intuitive exploration: the closer your hand gets, the higher the note, while pressing the sensor triggers the sound. It merges tactile interaction with sound, making music a physical experience.

 

Method & Materials:

This project was my first time working with two types of sensors on the Arduino Uno:

  • Analog Sensor: Ultrasonic sensor (HC-SR04) to measure distance.
  • Digital Switch: Force Sensitive Resistor (FSR) to detect pressure.
  • Output: Piezo buzzer to produce sound.

I connected the ultrasonic sensor to pins 10 (trig) and 11 (echo), the FSR to analog pin A0, and the buzzer to pin 12.
Each note from the C major scale (C–D–E–F–G–A–B) was assigned to a specific distance range, coded in an array:

int notes[7] = {261, 294, 329, 349, 392, 440, 494};

The system reads distance in real time:

  • When the FSR is pressed and your hand is between 0–50 cm of the sensor, the buzzer plays a tone corresponding to that range.
  • If no pressure is detected or the hand moves out of range, the sound stops.

Process:

At first, it took time to understand how analog vs. digital inputs work and how to read them simultaneously. I researched how to use pulseIn() for the ultrasonic sensor and experimented with mapping values using the map() function.
To visualize the notes, I placed colored paper strips at different distances  (each representing one note of the scale)

Throughout the process, I learned:

  • The importance of wiring correctly (e.g., ensuring the FSR forms a voltage divider).
  • How combining two sensors can create more expressive interaction.

Schematic:

Code:

This combines input from two sensors, an ultrasonic sensor and a force-sensitive resistor (FSR) to generate musical notes through a piezo buzzer. The ultrasonic sensor continuously measures the distance of my hand, while the FSR detects when pressure is applied. When both conditions are met (hand within 50 cm and FSR pressed), the code maps the distance value to a specific note in the C major scale (C, D, E, F, G, A, B). Each distance range corresponds to a different pitch, allowing me to “play” melodies in the air. The code I’m most proud of is the single line that transforms the project from a simple sensor experiment into a musical instrument. It defines the C major scale, turning numerical frequency values into recognizable notes. I love that such a short line of code gives the device its expressive character, it bridges logic and creativity, translating distance data into melody. It’s the heart of the project, where sound and interaction truly come together.

// --- Define musical notes (C major scale) ---
int notes[7] = {261, 294, 329, 349, 392, 440, 494}; // C D E F G A B

Result:

The final prototype acts like an invisible piano: you play by waving your hand in front of the sensor and pressing lightly on the FSR. Each distance triggers a different musical note. The colored papers made it easier to perform intentionally and visually mark pitch changes.

In the demonstration video, the tones respond smoothly to my gestures, transforming simple components into an expressive interface.

Challenges:

One of the main challenges I faced was understanding how each pin on the ultrasonic sensor worked. At first, I didn’t realize that every pin had a specific purpose, like trig for sending signals and echo for receiving them, so it took me a while to fully grasp how data was actually being measured. I also struggled with wiring the circuit, often making small mistakes that stopped the whole setup from working. Drawing out the schematic was another time-consuming part since there were many components to connect and label correctly. Finally, the coding process was challenging because it was my first time using several of these elements, and I had to learn through trial and error how to make the sensors and buzzer communicate smoothly.

Inspiration + Tools thats helped me:

https://projecthub.arduino.cc/theriveroars/simple-hand-controlled-instrument-372bfc

https://learn.adafruit.com/force-sensitive-resistor-fsr/using-an-fsr

Reflection:

This project taught me how code, sensors, and sound can merge into interactive art. The challenge was balancing sensitivity: sometimes the ultrasonic readings fluctuated, and it took some fine tuning. But once it worked, it felt rewarding to hear the instrument. It also made me realize how music can be built from logic, how creative coding allows emotional expression through electronics. I see this as the beginning of exploring computational instruments that combine art and technology.

Reflection- Week 9

When I read Physical Computing’s Greatest Hits and Misses and Making Interactive Art: Set the Stage, Then Shut Up and Listen, I started to think more deeply about what it really means to make something interactive. The first reading talked about how many beginner projects in physical computing repeat the same ideas, like using a sensor to make lights blink or to trigger sound. At first, I felt a little unsure because my own project also used simple tools like a light sensor and a button. But as I continued reading, I understood the real message: it’s okay to build something that has been done before, as long as I make it my own and give it a purpose. That made me feel more confident about my project. It reminded me that creativity doesn’t always mean doing something completely new, but doing something familiar in a meaningful or personal way.

The second reading focused on how interactive art should let people explore freely. It said that once we build something, we should “set the stage” and then step back, allowing others to interact with it in their own way. I really liked this idea because it made me think differently about my project. When I pressed the button or covered the light sensor, I realized that I was not just testing the circuit, I was actually engaging with it and discovering what it could do.

Both readings made me see that physical computing is not just about coding or wiring but it’s about creating an experience. It’s about giving people something they can explore and learn from on their own.

Analog Sensor

Concept

For this project, I used one analog sensor and one digital sensor (switch) to control two LED lights.

The analog sensor I used was a photoresistor (light sensor). It changes how much electricity passes through it depending on how bright the light in the room is. The Arduino reads this change and adjusts the brightness of one LED  when it’s dark, the LED gets brighter, and when it’s bright, the LED becomes dimmer.

For the digital sensor, I used a pushbutton connected to a digital pin. When I press the button, it turns the second LED on or off.

To make it different from what we did in class, I added a “night light” feature. When the photoresistor detects that the room is very dark, the button-controlled LED automatically turns on, like a small night light. When the light comes back, the button goes back to working normally.

This made my project more interactive and closer to how real sensors are used in everyday devices.

 Schematic of my circuit
It shows the Arduino connected to:

  • A photoresistor and 10 kΩ resistor forming a voltage divider to read light levels.

  • A pushbutton connected to a digital pin.

  • Two LEDs , one controlled by the light sensor and the other controlled by the button

Final Results

When I tested the circuit:

  • The first LED smoothly changed its brightness depending on how much light the photoresistor sensed.

  • The second LED turned on and off with the button as expected.

  • When the room got dark, the second LED automatically turned on, working like a night light.

It was a simple but satisfying project, and the extra feature made it stand out from the class example.

Video: video-url

Arduino Code

Part of Cold I am proud of

void loop() {
  // --- Read photoresistor ---
  int lightValue = analogRead(lightPin); // 0–1023
  int brightness = map(lightValue, 0, 1023, 255, 0);
  analogWrite(ledAnalog, brightness);

  // --- Button toggle ---
  if (digitalRead(buttonPin) == LOW) {
    ledState = !ledState;
    delay(200);
  }

  // --- Night light feature ---
  if (lightValue < 300) { // If it's dark, auto turn on LED
    digitalWrite(ledDigital, HIGH);
  } else {
    digitalWrite(ledDigital, ledState ? HIGH : LOW);
  }

  // --- Print readings ---
  Serial.print("Light: ");
  Serial.print(lightValue);
  Serial.print(" | Brightness: ");
  Serial.print(brightness);
  Serial.print(" | LED State: ");
  Serial.println(ledState ? "ON" : "OFF");

  delay(200);
}

Github url: Github

Challenges and Further Improvements

While I was able to make both the analog and digital sensors work, I struggled a bit with arranging all the wires and resistors neatly on the breadboard. It took a few tries to get everything connected correctly.

I also had to test different threshold numbers for the night light feature to decide when the LED should automatically turn on. Once I found the right value, it worked well.

For my next project, I want to try using other kinds of sensors, like sound or temperature sensors, and make the circuit respond in new ways. I’ll also practice reading the code line by line to understand how each part works better before adding new features.

Week 9 – Two-Degree Safety

My Concept

I decided to build a “two-degree safety guardrail.” The logic is based on two separate actions:

  1. Idle State: A red LED is ON (digital HIGH).
  2. “Armed” State: A button is pressed. This turns the red LED OFF (digital LOW).
  3. “Active” State: While the button is held, a FSR (force-sensing resistor) is pressed, which controls the brightness of a green LED (my analog output).

Challenge

My challenge was getting the red LED to be ON by default and turn OFF only when the button was pressed. I tried to build a hardware-only pull-up or bypass circuit for this but struggled to get it working reliably on the breadboard.

So, I shifted that logic into Arduino code adapted from a template in the IDE.

// constants won't change. They're used here to set pin numbers:
const int buttonPin = 2;  // the number of the pushbutton pin
const int ledPin = 13;    // the number of the LED pin

// variables will change:
int buttonState = 0;  // variable for reading the pushbutton status

void setup() {
  // initialize the LED pin as an output:
  pinMode(ledPin, OUTPUT);
  // initialize the pushbutton pin as an input:
  pinMode(buttonPin, INPUT);
}

void loop() {
  // read the state of the pushbutton value:
  buttonState = digitalRead(buttonPin);

  // check if the pushbutton is pressed. If it is, the buttonState is HIGH:
  if (buttonState == LOW) {
    // turn LED on:
    digitalWrite(ledPin, LOW);
  } else {
    // turn LED off:
    digitalWrite(ledPin, HIGH);
  }
}

The demo was shot with the Arduino implementation.

Schematic

However, I later figured out the pull-up logic, and was able to implement a hardware-only solution. This schematic was a result of the updated circuit.