Aakash’s Status Report for 10/26/2024

I have spent time this week working on the ethics assignment and building out a basic prototype of the timing algorithm. I have implemented the data structure I want to use which is a list of (pitch, onset time, duration) in python. I created a basic event list with uniform notes of the same pitch and duration with different onset times. I duplicated these and created a basic comparison between two lists. I also started working on the MQTT communication and setup an ingestion pipeline to take the data from the sheet music in the form of MusicXML and transform that into an event list.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is on schedule.

What deliverables do you hope to complete in the next week?

For the next week I want to continue to build up the algorithm by beginning to develop and test using data from the music xml files.

Team Status Report for 10/19/2024

Aakash’s Status Report for 10/19/2024

I spent the most amount of time working on the design document with my teammates. I worked heavily on sections regarding my sub-system which is the timing algorithm, while also making changes to our block diagram, and working on all the other miscellaneous sections to ensure the document was completed on time.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I am slightly behind schedule because I didn’t have as much time to work on prototyping as I thought last week because of midterms and the time spent working on the design doc. Overall it isn’t that big of a deal because my goals were ambitious for last week and I am still on track.

What deliverables do you hope to complete in the next week?

I hope to have a basic prototype of the timing algorithm done by the end of the week with a working demo with midi files.

Aakash’s Status Report for 10/5/2024

This week comprised of completing the design presentation and doing some initial prototyping on the timing comparison algorithm. I have built out a basic timing algorithm prototype in python using the expected data coming from the sheet music and audio data. From the sheet music I am getting data in the form of ‘d1/4′ for a note where the d stands for the music note d and the 1/4 stands for a quarter note. From the audio data I am going to be receiving a tuple in the form of (onset time, pitch) which is going to look like this:  (0, ‘d’) where 0 is the onset time and d is the music note d.

In terms of implementation I have been thinking about what kind of data transformations I want to implement in order to properly analyze this data. I have considered transforming the sheet music into an array based on the what beat we are on, but the issue with this is it doesn’t distinguish between a new note and a sustained note. Because we are focusing on note onset for this timing data, I was considering using this array, and only focus on note onset for this beginning prototype. For example, if I receive  the data [‘d1/4′, ‘d1/4’, ‘d1/2’, ‘d1/2’], because 1 beat is a quarter note, I would create a per beat data structure that would be [d, d, d, s, d, s] where s stands for sustained. I need to consider other edge cases such as notes that are less than a beat but that can be solved by just using an increment that is some fraction of a beat and scaling accordingly. 

I have also started a github repo to contain our project code and pushed some prototype code to this.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Progress is on schedule so far.

What deliverables do you hope to complete in the next week?

For the next week I want to focus on getting real data from the music we have recorded and determine what the current timing latency is with python and if I should use a c++ implementation. I also want to finish a basic prototype before spring break based on the data we recorded. I have three exams next week so I might not be able to accomplish all of these but I think that this can be reasonably done.

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

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.

Aakash’s Status Report for 9/28/2024

This week required a lot of brainstorming and thinking about how we were going to implement our project. I spent a lot of time working on the design presentation after we had an initial meeting with the School of Music musicians and collected some ground truth timing data.

I am ideating how to implement the timing algorithm because after discussing with Prof. Dannenberg it appears that real time feedback may not be feasible and that I should spend more time focusing on the post performance feedback. This means that most of the focus will be on post performance. I have attached my current plan for the timing algorithm below and will continue researching on how to deal with edge cases and complex scenarios with my teammates.

 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Progress is on schedule so far.

What deliverables do you hope to complete in the next week?

For next week the deliverables are going to be completing the design presentation and beginning to build out a basic timing algorithm prototype.

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.

Aakash’s Status Report for 9/21/2024

This week involved delivering the proposal presentation and finalizing some of our project details. My role in the project was to work on the algorithm to determine the musicians’ timings. Other than working on this presentation I worked doing some cursory research onto how we we would integrate the FPGA and Raspberry Pi along with coordinating some logistics around recording the musicians.

I also setup the WordPress website and made sure everything was good to go on that end of things.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is on schedule.

What deliverables do you hope to complete in the next week?

In the next week, I plan on researching Raspberry Pis and putting in a purchase order for one and beginning to record audio from the school of music performers and begin some cursory analysis of the audio recordings.