Revisiting last week’s goals:
- Use real EGG output data on playback page
- Done– we took more recordings with our vocalists, and put the real CQ, pitch, and audio signal into the playback page– after taking a number of steps to synchronize all three of these files
- Implement basic repertoire library page
- Done– the library allows the user to mark each recording instance with the song it’s related to, the name of the recording, and the date. The final column in this table allows the user to open up the playback view for the given song. I implemented a sqlite database with two tables (one for songs and one for recordings, with a one-to-many relationship between the songs and the corresponding recordings)
- Additionally, I created this “Add Recording” page where the user can create a new recording instance to add to this table, and can select the corresponding files to display. Additionally, the user can create a new song to link the given recording to.
- Complete one data analytics view
- Done – We added the view for seeing pitch on playback (as you can see under the first point), including the visual graph and the names of the pitches.
Next Steps
- Pitch vs CQ view
- The final feature to complete for the app side is a CQ over pitch analysis. Basically, the x-axis displays pitches, while the y-axis displays CQ. Multiple recordings from separate days can be loaded, to view the average CQ for the given pitch for each recording selected.
- Testing & verification
- Full integration with the backend
As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?
The main technology I had to learn for this project was, of course, the DearPyGui framework– I hadn’t programmed a Python desktop application since 15112, so I didn’t have much background to work off for this particular task. DearPyGui is a more obscure framework, chosen for its particular GUI features for things like graphing. However, this obscurity was a large downside to the framework, because learning resources were limited. I mostly used the DearPyGui documentation website, as this featured comprehensive explanation of components and functions, as well some limited examples. For more obscure glitches, I turned to the DearPyGui Reddit and Discord pages. Because of the small amount of resources, I had to do a lot of extrapolating from limited information to use in larger contexts. For instance, I wasn’t at first sure of how to create a multi-page display system within DearPyGui: I got information from these resources as to how to code the individual components for each page, but I created my own system for switching from page to page (creating a class for each page within the app, plus an app manager class) as the examples didn’t have that much detail.