Posted on

Team Status Report for 2/11

This week, we presented our project proposal to faculty and fellow teams. We received some insightful questions that we should keep in mind for our design. For instance, one question asked how we would interpret key words in music such as “rubato” that are not associated with specific tempo values. 

Our project includes considerations for safety, cultural, and economic. In regards to safety, our project will likely be dealing with a large amount of power due to the high current required by the solenoids. Limiting this power is an important consideration for the safety of us as well as the user. Culturally, we recognize that our sheet music parsing is centered more on Western styles of music which puts a limitation on the style of music we can play. Importantly, our project aims to lower the cost associated with piano accompaniment. Since the cost of hiring a professional piano accompanist is high, we can provide a more inexpensive alternative.

We have also begun the process of looking ahead for parts that will be needed. Since we have uncertainties about power consumption, we will be ordering and testing different solenoids for our key press mechanism. The biggest risk associated with our project so far comes with the issue of powering our worst case number of solenoids at once. To mitigate this risk, we have considered reducing the max number of keys pressed to three keys at once. This would reduce the current draw to below the max current of our existing power supply while still allow us to have a polyphonic system that can cover a three note chord.

Our identified OMR solution is looking pretty good so far. We have decided to go with Audiveris, and here is a sample of the transcription.

Original Music Pdf file:

Corresponding Transcribed XML

Posted on

Nora’s Status Report for 2/11

At the start of this past week I helped polish the Proposal Presentation slides in preparation for the week’s presentations. In particular, I created the Physical Implementation Model mockup as well as the block diagram. I also helped Aden prepare for the oral presentation.

Since my main responsibility area for the project is handling the microcontroller component, I have been brainstorming ways to organize the information from the XML so that the microcontroller can translate each individual note into scheduled signals that can be sent to the transistors to switch our solenoids on or off. Currently, I am envisioning a dictionary-like structure whose keys are certain “time” pointes (where the length of a time unit are determined by the tempo from the parser) and the values are a list of tasks to execute at the corresponding time (i.e. turn a specific solenoid on or off). When the microcontroller is playing a song, it will increment a counter for the time and retrieve the corresponding tasks at that time.

Since the XML file contains a lot of extraneous text, I will be working on providing Rahul with specifications for what should be kept in the file that is sent to the microcontroller. At a minimum, I will need the tempo value (or text description) of the piece and a sequence of notes with their pitches and duration.

We are planning on using a 30V 5A DC power supply that I have on hand to power our solenoids. Based on some preliminary power calculations using data from last semester’s Talking Piano group (since we don’t have access to the physical components to test yet), we determined that we would need a max power of (12V)(1.5A)(5 solenoids) = 90W for 5 solenoids turned on at one time. If the solenoids we end up buying draw comparable current, we may have to reduce the number of active solenoids to three at a time so that we are below the 5A limitation of our power supply. To lower the overall power so we meet the 60W average power requirement, I looked into the possibility of using a PWM servo driver for switching the transistors so that we can lower the average power. However, since PWM inputs for solenoids are used for position control, we would have to make sure it is still able to press a key down fully.

I requested a Raspberry Pi 4 from the 18-500 parts inventory, so I am hoping to set it up and familiarize myself with the environment in the coming week.

While I do not have any physical code written, I am ready to start implementing the data structures and initial algorithm for the scheduler. Thus I believe I am on schedule and should have completed a first pass implementation by the next status report.

Posted on

Rahul’s Status Report for 2/5

This week, I worked with Nora and Aden to finalize proposal slides. In particular, I contributed mostly to the technical challenges, UI application mockup, and software solution approach slides. I constructed my portion of the Gantt chart schedule and worked with Nora to settle dependencies in our timelines between production of XML data and processing of this data. I also wrangled with the initial setup for our website.

I have done some digging for good OMR tools, and have played around with the following. This first project I configured on my mac, but certain dependencies are unavailable. Here was another project that was research backed with a pretrained ML model. I was able to build and run this ML software, however I found its accuracy to be around 70-80% which is a little low for our project standards. Additionally, it only was capable of producing a monotone interpretation of a music score. A third project I looked at was Audiveris. After installing relevant JDK toolkits, I was able to get it working for Windows OS. I think this may be the way to go. It seems to have a robust note tracking algorithm in play, however it is only capable for converting scores to MXL format. Hence, I will need to do further research on how to convert this MXL format into XML or equivalent.

I believe I am on schedule at the moment. I will have to drop the small possibility of manually generating and training an OMR machine learning model. Just from the work and documentation that I have read, such a task is a capstone project itself. Ideally within a week’s time, I will have determined the best OMR solution for our project and have it up and running. To reiterate from the proposal, this solution will parse the notes into an XML/JSON style structure with >95% accuracy.