This week I was able to accomplish end to end connection of the accompanyBot with all of my team members. This was very exciting! I also discovered a bug while doing this. If the user opens the insert file menu while Audiveris is processing another file and then hits cancel on the new file menu the program crashes. This has been resolved now. Another issue that I have been aware of but cannot resolve is if Audiveris is busy processing and the user wishes to cancel the process or just decides to close the app preemptively. The Audiveris process dialog will continue running until it fully finishes. Considering that this OMR software is built upon very old toolchains and I already tried many options to get it configured for MacOS at the beginning of the semester, I will not dig into how I can send it a SIGKILL or similar termination signal. The easy work around is just to close the window that appears which terminates the process manually.
Earlier in the week, the interim demo took place. After showing the application, my team’s course advisor Tom suggested that I should add a digital player to demo the parsed music as a midi output before the accompanyBot starts to play. I was able to address this suggestion and implemented the digital player which converts the xml into midi first and then begins playing an endless loop. This loop can be paused and unpaused via the spacebar key.
In terms of completing my side of the serial communication I set up sender code and patched up the receiver thread code to get measure data from the notes scheduler running on the RPi. I also eliminated one piece of data that was initially being sent by the RPi. Previously, the number of measures in the song was getting determined by music21 and sent over the serial connection to the GUI app. I decided to process the number of measures algorithmically from the raw xml structure.
Overall, the project is in a good position. I was slightly worried last week that I would get behind, but after getting things working I believe I am on schedule again. Going into next week, I will have some more time to confirm the workings of the communication between subsystems. In particular I need to set up the ssh command to deliver the xml file from the GUI to the RPi. As mentioned earlier, this is necessary to avoid the one-time heavy load over the serial connection. If this gets done quickly then I can begin stress testing early and identifying problems that the GUI or notes scheduler may need to have fixed.
The tests on the application side will involve many different variations of quality of music inputs, randomization of button presses to break application, manual disconnection of serial cable while app is still running (I think I tried this already, and since I’m using threads for communication, they terminate with an error printed to the console, but the main app thread keeps running fine, so this is not unreasonable behavior I suppose), etc. I anticipate the app to crash when tests fail and will analyze the error logs closely to determine the point(s) of failure. Also, I will try to perform actions that spawn and terminate different threads at a time while checking the task manager to make sure all python processes get cleaned up when they should. Part of this effect on the use case requirements is to maintain the functionality and latency requirement between subsystems. In terms of design, the GUI should be user friendly. So any odd errors that prevent intended usage must be addressed.