Reverse Metronome

My project is the  Reverse Metronome, a  small device that helps me  understand what  BPM I'm  at while I play the drums.  After playing for a minute, the Reverse Metronome will tell me the BPM I'm currently at. This helps with not only noting the BPM of  songs, but also helping me know when I'm either rushing (a higher BPM than what I'm supposed to be playing at) or dragging (a lower BPM than what I'm supposed to be playing at). The  potentiometer knob assists with adjusting the  threshold of how hard  or soft I hit the snare such that each hit is accurately logged.

In this gif, you can see the LED screen switch from 842 BPM (caused by mounting the Reverse Metronome on the snare) to 100 BPM, which matches the BPM being playing on the snare.  The user hits the snare every 2nd and 4th beat in 4/4, and the Reverse Metronome sense this via the Accelerometer and gives the BPM output.

Process

Overall, the process was quite fun. I liked being able to explore all of the different steps it takes to create a product, especially one that I made to help myself! The most difficult part for me during this process was the creation of and the fitting together of physical parts. It was my first time using AutoDesk Fusion since high school so I was definitely very rusty. I also was quite nervous using the laser cutters because I was paranoid that I would set the entire place on fire. However, that did not happen! I actually found using the laser cutters fun. Glueing together the wooden pieces was quite satisfying as well.  As mentioend earlier, it was also difficult shoving electronic pieces into a wooden box. It was mainly a fear of breaking the connections with the electrical components and thinking whether or not the wooden encasing would break because of the amount of items within it. Besides that part, the physical creation of the device was not as bad as I thought it would be!

Discussion

From my experience, I learned a lot about the iterative process through the lenses of physical computation. This process has some similarities to the design iterative process, but obviously has some differences; such as receiving feedback from peers as a similarity and error checking as a difference.  

In particular, the final critique allowed me to think more deeply about the future steps I should take if I chose to continue with this project. One of the guests who attended our critique comments that there could be more features added to the metronome. One feature could include a sample value dial which would help teach people percussion. Another feature could have the metronome change based on how it is tapped on, which focuses on the y and z axises for different inputs. Both of these features are interesting directions to explore but may be too cognitively overwhelming within the same project. Out of those two features, I was really interested in using the y and z axises for different inputs. Currently, only the x axis is being used to monitor BPM. But, by tapping the Reverse Metronome in the y or z directions, how would this affect the experience of the user?

Another piece of critique I received was that the BPM should update at a faster rate. Rather than waiting an entire minute for the BPM to update, it should update almost instantaneously. This can mean after two measures of 4/4, after 2-3 minutes, etc.. This was a point I also brought up during my explanation of my product. If I had more time to focus on this project, I would have figured out a way to calculate the BPM without waiting an entire minute. One way to fix this would be to link the rests in between beats and calculate the time it takes between each hit and then translating it to a BPM.

Finally, I also wanted to address another piece of feedback that I really liked. One of the critiques stated that they wanted to see some sort of feedback whenever a hit is detected. I found that this is a great idea, especially when adjusting the threshold of the Reverse Metronome. The Reverse Metronome only uses 3 of the 4 digits on the LED screen because, I don't think someone would be playing more than 250 BPM. By having the last unused digit flash, every time a hit is detected, it gives the user even more immediate feedback about their playing. 

I feel satisfied with how the project came along. There were definitely some opportunities of improvement and I would iterate and implement all of the received critique feedback if given more time, or another round of iteration. I think this somewhat satisfied my goals because it definitely does the job. On the other hand, its slow at telling the BPM, which I won't fault it for because I was the one who programmed the device. Overall, this was a good step towards the right direction with this project.  I could see myself continuing to iterate on this project and exploring the critiques I was given

From this project, I learned that there are a lot of tools at my disposal. This can especially be seen in Ideate in general. There are many tools, gadgets, and materials that could be used to enhance projects. For example, I didn't know there were different types of LED screens for us to use, some of which being more complicated to wire compared to others. I also found myself enjoying laser cutting and 3D modeling. I will definitely take advantage of laser cutting throughout this year. Laser cutting is definitely a nice and useful skill for me to have under my belt when it comes to making practical things for fun. 

If I were to do this project differently next time, I would look into adjusting the BPM to change every few seconds / measures rather than a full minute. One of the reasons why the code was fairly simple was because I did not have enough time to truly immerse myself within the creation of the project. Instead of getting hung up at a particular point in progress, I should have stayed more hung up on the process of translating hits to BPM instantaneously. Because of the tight turn around for this project, I didn't give myself enough time to fully digest deep issues of BPM translation. I wanted to focus more on getting a presentable project up and going. Now that the assignment is over, I may find myself in the Physical Computing lab working on my Reverse Metronome!

For my next steps, I would definitely build after iteration of this project. I would implement the suggestions made in my critique: the BPM updating at a faser rate, adding different axis directions to change output, and adding a digit that flashes whenever a hit is made.

Technical information

/*

Reverse Metronome

Janelle Tecson

This code is for the Reverse Metronome. After 1 minute of playing, it tells the

user what BPM they were playing at. They can use a potentiometer to adjust the threshold

sensitivity of the device depending on how hard or soft the user hits the snare drum.

pin mapping:

Arduino pin |   role | description

___________________________________________________________________

A0           input      detects X axis movement

A1           input      allows for user to adjust threshold as needed

A3           output     displays information on LED screen

A4           output     displays information on LED screen

Code released to the public domain by the author, 10/24/2024

Janelle Tecson, jtecson@andrew.cmu.edu

*/

#include <Adafruit_GFX.h>

#include <RTClib.h>

#include "Adafruit_LEDBackpack.h"

#define DISPLAY_ADDRESS   0x70

Adafruit_7segment matrix = Adafruit_7segment();

RTC_DS1307 rtc = RTC_DS1307();

// Pin definitions for the accelerometer

// only interested if X jumps

const int ACCEL_X_PIN = A0; // Analog input pin for X movement

// current position

int accelXPos = 0;

// previous acceleration values (for calculating change)

int prevAccelXPos = 0;

// Define a threshold for hit detection

// adjust using a potentiometer

// i.e. if hitting drum lightly, turn down threshold but if hitting hard, turn up threshold

int threshold = 70;

// potentiometer pin

const int POTENTIOMETER_PIN = A1;

// Variables for BPM calculation

unsigned long previousMillis = 0;

unsigned long interval = 60000; // Time interval for BPM calculation (60 seconds)

int hitCount = 0; // Number of hits detected

void setup() {

  // Setup serial port to send the accelerometer data back to the computer

  #ifndef __AVR_ATtiny85__

  Serial.begin(9600);

  Serial.println("setup complete");

  #endif

  matrix.begin(0x70);

  // Setup the accelerometer inputs

  pinMode(ACCEL_X_PIN, INPUT);

  // potentiometer pin

  pinMode(POTENTIOMETER_PIN, INPUT);

}

void loop() {

  // Read the accelerometer values for X axes

  accelXPos = analogRead(ACCEL_X_PIN);

  // Read potentiometer value to get current state

  threshold = analogRead(POTENTIOMETER_PIN);

  // Calculate the change in acceleration (vibration)

  int deltaX = accelXPos - prevAccelXPos;

  // Update the previous values to the current ones for the next loop

  prevAccelXPos = accelXPos;

  // // Detect a hit if the change exceeds the threshold

  if (deltaX > threshold) {

    hitCount++;  // Increment the hit count

    Serial.println("Hit detected!"); // For debugging

  }

  // // Check if the interval time has passed

  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {

    previousMillis = currentMillis; // Save the last time we calculated BPM

    // BPM is the number of hits in the last 60 seconds

    // multipled by 2 because 4/4, snare usually only hit on the 2 and 4

    int bpm = hitCount * 2;

    // Display the BPM on the 7-segment display

    matrix.println(bpm);

    matrix.writeDisplay();

    // Reset hit count for the next interval

    hitCount = 0;

    // Send the BPM data over serial for debugging

    // bpm not being calculated accurately, maybe too sensitive?

    Serial.print("BPM: ");

    Serial.println(bpm);

  }

    Serial.print("threshold: ");

    Serial.println(threshold);

  // // Small delay to avoid flicker

  delay(20);

}