Significant risks for the project we managed this week:
-
This week we finally get the Advanced MIDI pattern matching done!! It’s working on test cases we created virtually, and we are going to test the algorithm, and move on with live MIDI pattern matching design next week (after Spring Break).
- After trying out the Levenshtein distance method as mentioned last week, we found that the melody extraction part actually introduces more bias to the original midi slice. Since our target is not to find slices with similar melody but slices with similar note components and sequences.
- Now we think it’s more important to recognize the sequence of the notes being played so as to perform the matching algorithm with higher accuracy. We decide to first group chords in the original MIDI data, and then generate patterns that match with the sequences of the chords/single notes in the original MIDI file (sequence of notes within the same chord being played live should not make a difference to the matching result). We still use the Euclidean Distance as a similarity metric.
-
Because the campus is shutting down due to coronavirus, we are having a very difficult time to keep up with out hardware implementation plan. We left the Pi, all motors and servos in the HH1300 wing and now there’s a chance for unable to retrieve our items back.
-
The Pi requires school network, motors require DC voltage input from the lab, so all that couldn’t happen even if we retrieve our electronic components back.
Changes made to the existing design of the system:
An updated schedule if changes have occurred:
-
Changed the schedule because not sure how long note recognition will take and have some experience with a web application so that time is predictable and decided to finish recognition first
-
Change to use Solidworks to simulate how the motor controls the shaft and flipper.
-
Change from physically running the code to writing the code and demonstrate the intention of the code to prove of concept
0 Comments