Team Status Report for 2/21

Progress has been going well this week. Since we just finished up with the design presentations, we feel really solid about all of the work we have ahead of us and feel on track.

Caleb has gotten to work on some of the hardware side of things and has written some transmitting logic in C++ that is working well within our latency budget. The biggest risk we see for ourselves right now is not getting all of our hardware in time and not being able to test it properly. We are confident that we can sink enough time into the software side and get it working, but if we don’t even have access to the critical hardware we need, we are most fearful about that. Once we get the piezos and other parts we need, we will be able to test our implementation out and feel more confident.

On the software side, we are still doing good. Rishabh has been working on implementing more of the game logic and has made good progress on that. Meanwhile, I have been doing research into potential ML solutions for extracting drum sounds from a .wav file.

There was one small change we made in our software architecture. Originally, Rishabh was using demucs and a Fast-Fourier Transform that he implemented to extract drum sounds from a song’s mp3 file. However, the issue with this is that FFT is limited to only extracting 3 sounds from the .mp3/.wav. Therefore, Abishek worked on getting an ML solution working for this. More details can be found in the individual status report.

Abishek’s Status Report for 2/14

This week, my primary focus shifted toward refining the overall system and game design, as well as contributing to the design presentation to better articulate how users will interact with the platform. Rather than implementing features directly, I spent time thinking through the structure of the learning experience and how gameplay mechanics can meaningfully support skill development for beginner and intermediate drummers.

Specifically, I designed a level-based learning system in which users progress through increasingly difficult stages (easy, medium, and hard). Each level consists of a song that the user plays along with, while the system tracks performance by comparing expected drum hits against the detected input from the pads. A “miss” can be defined as either failing to hit a required note within a fixed timing window or hitting an incorrect pad. At the end of each song, the user is presented with a performance summary showing the number of correct hits versus missed notes, along with an overall accuracy percentage. If the user achieves greater than 95% accuracy, they are allowed to advance to the next difficulty level. This structure provides clear, measurable feedback while still keeping the experience game-like and motivating.

In addition to the core progression system, I also thought through extensibility of the platform. One important design goal is to allow users to upload their own .wav files so they can practice with songs they enjoy, rather than being limited to a predefined library. This introduces additional challenges around difficulty classification and timing extraction, which will need to be addressed in future weeks, but it aligns well with the project’s emphasis on flexibility and personalization.

Because my efforts this week were primarily focused on design and planning rather than implementation, I am slightly behind in terms of direct software development. However, I believe this time was well spent, as it clarified the requirements for the game logic and will make future implementation more structured and efficient.

My next steps will be to help decide and curate which songs belong in the easy, medium, and hard categories, and to begin translating this game design into a minimal interactive prototype. This will involve defining the exact criteria for hits and misses, implementing basic game state transitions, and preparing the interface to accept timing and sound information from the drum detection pipeline once integration begins.

Abishek’s Status Report for 2/7

As Caleb mentioned in the proposal presentation, a lot of the work for this project can be parallelized across the hardware and software components. This week, I mostly brainstormed about possible game ideas and ways to implement it. I did some research on possible game engines and it came down to either Unity (C#) or Bevy (Rust).

Unity seems to be the more fleshed out project and will possibly have better community support, but learning C# might be a high barrier.

Rust on the other hand is less of an overhead since I have already used it before, however getting Bevy to read input from our hardware could potentially be more complicated based on my initial exploration.

By next week, I hope to have a clearer picture over the pros and cons of both game engines and finalize a decision (and also get aligned with Rishabh on the choice of what platform to use to design the game engine). Furthermore, I also want to start finalizing a plan for how we will process the user data to adjust game difficulty. This might be through some sort of simple ML model or other rule-based evaluation.

I would say we are on schedule.