Significant risks for the project we managed this week:
-
The difficulty of performing the advanced MIDI matching algorithm on complex sheet music
- Although testing of the advanced MIDI matching algorithm went well last week with the file Piano_Man_Easy, when we tried to test the advanced MIDI pattern-matching algorithm on another file: Penguins_Game.mid. which contains significantly more chords and obviously notes than the song Piano_Man_Easy, it takes much more time to match the MIDI pattern every time, with the time needed ranging from 0.18s to 8s.
- Different [window] size, which specifies the number of live notes collected before fed into the MIDI matching algorithm, results in significantly different processing time as well.
- However, it is indeed a tradeoff between the accuracy and the speed. As reported by the program, the time needed to prepare the info dictionary of the original midi file which is later needed for MIDI pattern-matching is 0.1s when [window] = 5, and exponentially grows to 35s when [window] = 10. However, if [window]=5, since there are lots of repetitive sections in the sheet music, the accuracy of the live matching is not very desirable; it is only capable of doing MIDI matching correctly if the user is playing exactly what is written on the sheet music. When [window]=10, the accuracy is desirable, and the matching algorithm can even perform correctly when the player rolls back several measures, repeat nearby measures, or play about 30% error notes. Yet, the matching algorithm runs rather slowly and results in glitches during the pattern-matching.
- We are waiting to see if the issue can be solved after the code gets migrated onto AWS on an instance with sufficient storage and computation power.
Changes made to the existing design of the system:
- Refer to previous Post
An updated schedule if changes have occurred:
- Refer to previous Post or link here
0 Comments