Team Status Report for 2/25
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
As of now, our most significant risks come from our pitch detection algorithm being accurate as well as our web application latency being able to both send audio into a python module and display complicated graphics.
As Kelly is working on the pitch detection algorithm, she’s taking her time in testing it out in the following environments:
- In a quiet room with just the headset and minimal background noise
- In a standard college hall with a conversational level of background noise
She’s also currently testing on pitch detection on the following:
- A self-made C Major Scale Slow
- A self-made C Major Scale Fast
With time and thought put into testing as well as considerations put into why the algorithm may be failing (i.e noisy environment vs. the note changes happen too fast), we’re hoping that we’ll have a better idea of what preprocessing we’ll have to do on the audio, if any, as well as what our biggest disadvantage is. As of now, our contingency plan is to preprocess our audio and in the worst case if latency does not hold, move to another pitch detection software, possibly implemented in C that Anita has researched.
Anna has been working on the web application and hopes to figure out our realistic latency by integrating the basic pitch detection algorithm to her application and see just how long it takes to display feedback as well as get the pitch from the backend. Risks here are being mitigated by integrating the backend one step at a time. Anna has been very diligent about breaking this arduous task up into first playing audio, then have a dummy python backend that can communicate, then record the users voice and send it to the backend to see how long it takes to come back with information. An obvious fallback here is to handle the pitch detection asynchronously instead of real-time as we’re hoping.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
Currently, we added some use case requirements. As Anita stated in her report, the idea of relative vs. absolute pitch was brought up and we would like to accommodate relative pitch in our design. This comes at the cost of a potentially higher latency, but it also improves the accessibility of our product. Our product is marketed for beginner singers and thus every beginner should be able to use it, so we were quickly able to justify this change.
These costs will be mitigated moving forward by picking a good pitch detection algorithm that will limit the amount of preprocessing we’ll need to do on our recorded input.
This is also the place to put some photos of your progress or to brag about a component you got working.
This week, Anna has some preliminary graphing structure added to the webpage!
Additionally, Kelly was able to put together several mp3 files (as seen in her 2/25 report).
Enumerate how you have adjusted your team work assignments to fill in gaps related to either new design challenges or team shortfalls (e.g. a team member missing a deadline)
So far, our team has been working very hard to stay on schedule, but we did have to pivot our team’s structure quite a lot in light of no longer using a home grown pitch detection algorithm. Due this change, Anita no longer had a big task to work on and so we split up the pitch detection from the scoring and feedback process. This way, Kelly is focusing on pitch detection and accuracy, Anita is focused on feedback and scoring, and Anna is still focused on web application development. These tasks are all parallelizable, which we were very set on if we were going to get this project done on time. Additionally, the pitch detection algorithm testing managed to be a bigger task than we had originally planned for as Kelly needs to manually modify and in some cases create an audio file to compare the recorded vocals to. Thus, taking the work of the feedback and scoring off of Kelly was the right move for our team.