For this week, I had to build out a lot of the framework for the GUI application. Everything I did was able to be successfully implemented in python (alongside the Audiveris and powershell scripts I had written last week and early on in the semester).
This included, adding a variable tempo metric display, controlling this tempo with key presses or mouse clicks on the bi-directional vertical arrow buttons, displaying the pause button when the play button is clicked and vice versa, adding a variable current measure number, creating a slider that controls the current measure number (with equally spaced stops at the integer measures determined by the total number of measures in a piece/song), allowing the measure number to also be more fine-tuned to decrement from bi-directional horizontal arrow buttons.
I also successfully integrated Audiveris into the application, by making a seperate thread call to the OMR program after the file opening thread returns the string of the selected file. Since users may select invalid files, I implemented some basic error handling here as well. Once the OMR parses the music score into XML, it stores it to a cache folder and then the application renders the png of the score into the application for display above the slider. I discovered that pdfs are slightly more complicated than pngs as they consist of multiple pages. Nonetheless, I did some digging and came across the “pdf2image” module for python. Since the app runs on Windows, I had to install and configure an additional library known as poppler to get pdf2image to work properly. With that done I was successfully able to display the pdf music scores in the event the users input was a pdf, which we deemed as valid input in our proposal and design review. At the moment I am only displaying the first page always. Once the notes scheduling portion of the accompanyBot is integrated, I will look to ensure the proper page is being displayed at all times.
This is a short demonstration of what is possible from the GUI as of March 25, 2023.
I also believe I can attempt to offer a more formal definition of what valid input is. In previous work my group and I have done, we just said no handwritten or low resolution scores. Quantitatively speaking, I would say the scores that should be generated need to be at least 400 DPI, otherwise Audiveris begins to have some problems assigning note heads and rests to the scores.
I ran into a bug with pygame not being able to display some of the lower resolution scores that Audiveris was just barely able to process (they were roughly 240 DPI). I will try to look into this, but I did get these pages off the internet, and to crack down on copyright infringement it seems a lot of free content is being made available only at lower resolutions.
My goal for the week was to get as much of the app done that does not require integrating with the RaspberryPi. I think I was able to accomplish that successfully. My schedule for next week states I should be helping with hardware construction and circuitry. Considering my strengths are in software and that we are behind schedule on the implementation of the notes scheduling portion of the accompanyBot, I will shift my time to be spent helping get that done. Nora is working to finish that up, so if she does have it working early in the week then I will instead work to integrate it with the GUI application that I have spent the last 2 weeks building. The new schedule will be updated accordingly.