We successfully were able to demonstrate our product with a working UI for our guitar hero game with 3 pads or 3 inputs. We were able to adjust the difficulty of the song on the spot, reduce the number of double hits and mis-inputs, and overall have a positive user experience.
Hardware: Our hardware was mostly working as expected without much noise detected however we did experience some scenarios where we did run into potential issues. (1) Our initial drum pad design had a case that wasn’t flush to our impact plate and thus residual hits would tamper with the impact plate and cause multiple hits to be registered. Furthermore this could be an issue with the overall drum not being tight enough. (2) Our newest pad did have some issues with double hits and as I described in Caleb’s Status Report, it could be an inherent characteristic of the acrylic impact plate. This can be accommodated with some software fixes and maybe some dampening circuitry. (3) Lastly, our drum frames are in direct contact with the table that it is on which gives rise to some noises being picked up from table hits and I believe it can be lightened with rubber stop gaps between frames but also between screw and the floor.
Hardware Test: Caleb will then conduct a series of 25 consecutive hits in 3 sets: control represents dead center hits, group 1 which consists of hits to the area between the center of the drum and the rim, and group 2 which consists of hits only to the rim. Then I will check the outputs on my serial monitor from the daisy seed and find the percentage of hits that result in a double hit being registered. From these fixes I am hoping to lower the percentage of ghost hits to <8% (only 2 ghost hits for every 25 hits). One thing to note is that there are some instances were double hits are intentional, if the grip on the drum stick is very loose causing the bouncing of the stick head on the drum pad.
Secondly, latency was a big concern of ours so I will hook up one end of an oscilloscope to the output of a piezo pin on the drum then I will hook up the other end to the tx port of the daisy seed to be able to determine the difference in time of arrival of each packets and ensuring that the time difference is within our limits of 10-20 ms with 5% tolerance. (9.5-21 ms)
Software: We got the overall game functional, the extraction of the drums from a song work well in regards to any type of music file inserted, however the pipeline does take a lot of time. Due to us having to convert a song into wav file, pushing it through demucs which takes 2 ish minutes to parse the drums out of. We manually went through one song and compared the drum music sheet with the notes being outputted to find there was a 95% match rate which is great news.
Some difficulties we faced was moving our ML model from an x86 proprietary driver model to a more open model which has helped streamline our process a lot. And also receiving ghost screens very seldomly.
Steps we can take for the future of our software interface is (1) improving the UI so that players can easily tell the difference and arrangement of pads, (2) improving the gameplay so that players know how well they are doing (numerical feedback system and normalized score tracker) so that they don’t lose interest, (3) implementing the networking interface so that we can simultaneously run 2 independent pad systems playing a single game on 2 different computers.
Software Testing: Most of our software testing will probably take the form of user experience feedback in the early stages because we want to improve the gaming aspect with a point system that is incentivizing for our users. Including checkpointing system to accommodate for beginner drummers. And then we will move on to stress testing our networked model with multiple data packets to ensure that our timing between client and server is synced and we do so without a lossy network.
Overall, we would say that we are on track to being able to finish our product by the final deadline but also on track with our schedule.