Category: Team Status Reports

Posted on

Team Status Report for 12/7/2024

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?

The most significant risks at this point in the project are just significantly lower accuracy for complicated pieces of music. While we can keep working to improve the accuracy, this isn’t that big of a deal because we are having success with easy and medium tiers of music and should have more than enough to demo with.

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? 

No changes made at this time.

Tests

List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

We tested the system on three different levels of music, easy medium and hard.  And we tested each of our five metrics, pitch, onset time, onset duration, alignment and delay.

In the timing algorithm we tested to make sure that the notes from the audio data aligned with the sheet music. This was manually verified as there was no way of automating this but we checked the similarity of the pitch, onset time, and onset duration of the two notes that got matched together.

To test the delay between the singer and the sheet music, we did a basic test where we tested to make sure two pieces with no delay didn’t have any delay feedback given by the system, and a pieces with a constant 5 second delay and make sure there was always a delay in all parts. This was done with a medium piece which was Fly Me to the Moon.

For the sheet music scanning, we ensured that the scanner

Overall, we found that most of our difficulties come with processing the piano music.

Posted on

Team Status Report for 11/30/2024

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?

The most significant risk as of now is that the system won’t be performant on a raspberry pi and that some pieces of music won’t be able to be processed. In order to mitigate these risks we always have the use of a laptop as a backup as we know the system works well on that and to limit the scope of the pieces we use for the demo. This will allow us to have a fully working demo no matter what and be able to show off the functionality of our system without working with unknowns.

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? 

No changes made at this time.

 

Posted on

Team Status Report for 11/16/2024

Now that you have some portions of your project built, and entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

Verification is usually related to your own subsystem and is likely to be discussed in your individual reports.
Validation is usually related to your overall project and is likely to be discussed in your team reports.

For validation tests, we want to ensure that when the system is given the same inputs, we get the same outputs every time. This can be done by giving the system the same sheet music and audio data and ensuring the music highlighting is the same.

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?

So for the most significant risks are that we cannot properly process complex pieces of music. This risk is being managed by slowly increasing the complexity of the music we process to ensure that we don’t have any surprises as we test more complicate pieces. The contingency plans we have are to just stick with simpler pieces of music because it is working so far so if there are complex pieces of music we have trouble processing, we will treat them as edge cases and focus our energy on polishing what we know works.

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?

No changes made.

 

Posted on

Team Status Report for 11/9

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?

We still have the risk of system integration as we are all having success with our individual parts of the project, but we haven’t spent much time integrating them and seeing if there are any weird bugs or edge cases. This can be mitigated by starting to to integration soon so we have ample time before the interim and final demo to make sure our system is stable and reliable.

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?

No changes made.

 

Posted on

Team Status Report for 11/2

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?

The risks to the project as similar to what they are before. We are planning to have a basic demo prepared for the musicians on Wednesday. From this demo we will try to see how much the imperfect accuracy of each component effects the overall systems ability to provide feedback and adjust the specifics of the system accordingly.  A contingency plan if adjustments don’t fix the issues would be to simplify the pieces played to pieces where we know we can have a high accuracy for.

 

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?

Changes made: None

Posted on

Team Status Report for 10/26/2024

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?

The most significant risk that could jeopardize the success of the project is the accuracy of each sub component. Neither the sheet music scanning component nor the audio component will be able to have 100% accuracy meaning the timing algorithm will have to be able have some level of tolerance for that. For example if we classify a note duration for the pianist correctly but the singer incorrectly that can mean we incorrectly identify that they are out of sync. Currently we are managing this risk by ensuring that the duration classification is as high possible however this does not completely mitigate the risk. If this ends up being a significant issue then we can allow the user to manually edit the duration of certain notes so that if they notice that they are consistently getting out of sync after a certain point they can override the MusicXML we have with the correct duration.

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?

Changes made: None

Posted on

Team Status Report for 10/19/2024

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?

The most significant risk that could jeopardize the success of the project is the accuracy of each sub component. Neither the sheet music scanning component nor the audio component will be able to have 100% accuracy meaning the timing algorithm will have to be able have some level of tolerance for that. For example if we classify a note duration for the pianist correctly but the singer incorrectly that can mean we incorrectly identify that they are out of sync. Currently we are managing this risk by ensuring that the duration classification is as high possible however this does not completely mitigate the risk. If this ends up being a significant issue then we can allow the user to manually edit the duration of certain notes so that if they notice that they are consistently getting out of sync after a certain point they can override the MusicXML we have with the correct duration.

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?

Changes made: None

Special Topic

A was written by Aakash, B was written by Mathias  and C was written by Ben.

Part A: Our project has impact on global factors as it helps democratize access to musical timing feedback to people that may not have access to a music teacher or coach. By having a system that is able to be run on a laptop and provides feedback on the timing of a duet, we are able to help people who are just starting to perform together and may struggle with performing with another person. For some, this may take a while to get used to, but our system can help them get acquainted with performing with new people and new pieces faster so they can progress as musicians.

Part B: Our project has an impact on cultural factors as it can allow people to learn how to play songs that would normally outside their culture. Our system can assist people in learning songs that they are not familiar with and due to the ease of use of the system it may encourage people to learn to play songs from outside their culture or what they normally play. This can allow for more more people to experience cultures outside their own.

 

Part C: .With respect to environmental factors, our system does not have many considerations as the scope of the project does not include accounting for power consumption. Since the system is entirely electronics, the environmental impact is limited to how much system uses to operate. Since we are using off the shelf hardware there is not much to be done about reducing power consumption

Posted on

Team Status Report for 10/5/2024

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?

The main risks to the project are the complexity of each subsystem. For the music scanning element, due to the diversity and complexity of sheet music, it is possible that the accuracy of this system (which is already a challenge to piece together using the existing open source libraries) is not sufficient to meet the overall needs of our system. The contingency is to use MIDI inputs instead of a PDF which have a well defined library in multiple languages. For the algorithm, the risk is dealing with similar edge cases. Music is inherently subjective but focusing on beginner and intermediate musicians means the algorithm can be more strict to focus on more rigid timing than would be needed for more advanced musicians who already posses the skill and play with tempo (and cause more musical variation difficult to process). Overall, once a basic iteration is developed, it will simply continue to be optimized as the semester continues. Lastly, the audio processing itself seems to be challenged by real-time input. Since real-time DSP is its own challenge, the starting place to mitigate risk is to use pre-recorded audio files as the initial input. Should real-time fail to be successful, musicians could still upload their recordings into the system and receive feedback. It would be an extra step on the part of the user, but still work as a functional system.

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?

No changes since last week.

Provide an updated schedule if changes have occurred.

No schedule changes.

Our current Gantt Chart: https://docs.google.com/spreadsheets/d/1w5bFU-YbyqIHIdWTXLG7f4z9ygEWPRjl9v7tBey53n8/edit?usp=sharing

Posted on

Team Status Report for 9/28/2024

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?

The most significant risks that could jeopardize the success of this project are edge cases in the music that can’t be properly analyzed for timing requirement and being unable to register all notes in that are being recorded by the musicians. This can be mitigated by changing the scope of our project by using simpler sheet music and having a more generous error tolerance to account fo those edge cases.

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?

A major change we made to the existing project design was pivoting from the FPGA to a computer for the audio signal processing. This was done at the guidance of Prof. Dannenberg as he stated using an FPGA would be unnecessarily complex and a computer would still fulfill the necessary latency requirements.  The audio processing is still a substantial task and the switch will not take away complexity from the project.

Provide an updated schedule if changes have occurred.

Due to the pivot, any FPGA related tasks have been changed. The audio processing task list and schedule has been updated as follows:

 

In the team report, please include A was written by Aakash, B was written by Ben and C was written by Mathias.

Part A: Our solution does not apply to considerations of public health, safety or welfare because we are working on a tool that helps musicians with performances. While getting better at performance can help someone’s psychological safety, there are no real physical safety or public health considerations to be made in this regard because we are just giving feedback and not impacting the real world.

Part B: Our solution involves music which is an innately cultural and social element. Our background and approach is from a Western perspective; the main bulk of our testing audio is gathered via musicians with Western Classical training. Though our design is mainly focused on synchronicity, generally a universal trait of all music, there may be some bias towards a specific feedback outcome informed by the style of music we are used to. That being said, the design, at a high level, is intended to aid in the creation of social experiences.

Part C: Our solution may be able to help people in terms of economic factors due to the application being provided being free. Traditionally music coaches can be pricey and although our application isn’t a complete substitute for a coach it can allow people who wouldn’t normally be able to afford one access to musical feedback that they wouldn’t otherwise have.

Posted on

Team Status Report for 9/21/2024

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?

The most significant risks that jeopardize the success of the project is having the timing algorithm not work correctly. This risk is being managed by collecting a lot of music audio to ensure we can have a working algorithm for the demo. A contingency plan is to limit the scope of the project to music that is easier to break down if we find having support for all music to be too complex.

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?

There are no changes to the design of the system at this time.

Provide an updated schedule if changes have occurred.

No schedule changes at this time.