Posted on

Team’s Status Report for 3/9

Part A written by Lin:  Identifying that saxophonists may come from very diverse geographic locations and backgrounds, our system ensures accessibility for users worldwide. We choose to build a web app instead of a phone app so that it’s more convenient and accessible. We aim to make our web app interface intuitive and user-friendly so that people with different educational levels can all use it easily. We also want to include a learning page in our web app to help saxophone beginners worldwide learn better.

Part B written by Junrui:  This project takes into account cultural factors by emphasizing the universality of music as a learning tool. Although offered in English with a set selection of songs, our design is mindful of the diversity in musical practices and the educational needs of users from different cultural backgrounds. This project avoids cultural bias by focusing on the technical aspects of saxophone playing, which are common across cultures, thereby ensuring inclusivity.

Part C written by Jordan: This project focuses on helping beginning human players get better at saxophone. Helping human players get better at saxophone can help the environment by removing unpleasant noises from the environment, especially around aspiring saxophone players.

Our most significant risk right now is that the audio processor has some bugs that haven’t been fixed yet. If the pitch detector doesn’t perform as we expected, the inaccuracy rate of the overall system will be very high, which is not acceptable. To resolve the issue, Lin will make extra work in the following days and ask for TA and professor’s help if needed. Another risk is that the hardware construction for fingering collection is a little behind the schedule. Jordan will take his effort to catch up next week.

We have made a slight change to our design. We decided to focus on offline audio processing for now instead of real-time due to scheduling issues. If we finish the audio processor earlier than expected, we will work on converting it to real time. But if not, we will stick to offline processing. Other than that, our design stays the same as it was in the design report.

Posted on

Jordan’s Status Report for 3/9

I was sick during the week of 2/26, and since most of my work at this stage involved going to the ECE labs and assembling components, I could not get meaningful progress this week. I was also away during the spring break week. Despite this, I shifted some work from later schedules, by writing up some thoughts about the feedback portion of the web app for later use. I wrote the following by playtesting the saxophone myself.

Here are the gist of the work this week:

Fingering correct, sound correct: no feedback, good job!

Fingering correct, no sound: check embouchure to make sure the wind blowing into the saxophone is consistent.

Fingering correct, sound pitch slightly higher than expected (below one note difference): loosen up the embouchure.

Fingering correct, sound pitch slightly lower than expected: tighten embouchure.

Fingering correct, sound pitch more than one note higher: likely biting, please stop biting on the mouthpiece and play looser

Group feedback after a playing session, if sound pitch consistently higher or lower than expected: higher -> pull out mouthpiece, lower -> push in mouthpiuece

My schedule is behind by about a week now due to the sickness, but I do have failsafes built into the schedule that allows me to be late for up to one week. I will try to finish the assembly of the saxophone fingering collection system in three weeks, allowing three weeks for integration.

Specifically for next week, I will put together a 8-note fingering collection system on a breadboard to ensure that the system is able to record the fingering.

Posted on

Lin’s Status Report for 3/9

This week I’m mainly focusing on revising my code for the pitch processor. I tested eight different saxophone music files as inputs and the outputs are not very accurate. Sometimes the output is correct, but sometimes the output is very wrong. I believe that there’s some miscalculations in my code and I’m still revising and repairing it. I tried to modify the code to use FFT instead of STFT but it turned out to be worse, so I decided to stick to STFT. For the rhythm processor, I decided to work on an offline processor instead of real time since I did some research and found that real-time processing requires far more work. I will finish working on offline processing first and then work on real-time if I have time left. 

(For example, the output notes here is a mess)

I’m slightly behind schedule this week due to the unexpected pitch processing error. I’m working to fix the issues and I expect to fix it by Monday. After that I will keep working on the rhythm processor and test several saxophone musics played by Jordan as inputs. 

Posted on

Jordan’s Status Report 2/24

This week, I started testing components for the saxophone fingering collector build, as well as starting some initial assemblies. I have tested all hall effect sensors, and confirm that they all work. However, the output voltage doesn’t get detected by the ESP32 controller just yet, so I need to do further testing next week to find working conditions.

The biggest delay is the slow speed in the production of the PCBs. Due to unfamiliarity with the process, there were several delays in placing the order to the vendor, delaying the timeline by 5 days. This means that I am slipping behind schedule, and it may push the completion time of the assembly by 1-2 weeks.

Since I cannot speed up the PCB process, I will divert some of my attention to the software side of things when I am finished with the voltage issue of the hall effect sensors.

Posted on

Lin’s Status Report for 2/24

This week, since I’m the presenter of my group, I prepared for the design review presentation on Wednesday. I did a lot of practice to make sure I don’t need to look at notes during the presentation. Aside from the presentation, I researched on how the rhythm processor could work since my previous work mainly focused on pitch processing. After reading some past research and projects, I decided to use a window size of 1/8th of a beat. 

I also looked into Librosa to see how to find peaks for an input audio of 1/8th of a beat. I didn’t find the function but I found there’s a find_peak function in the Scipy library, so I decided to use that. However, the code still has some bugs right now and can not detect peaks correctly. 

I am slightly behind the schedule this week since I have both the design presentation and midterm paper due. I will definitely work harder next week to keep up with the schedule. I want to finish debugging my code by next week and test with some input audios generated from a real-life saxophone.

Posted on

Team’s Status Report for 2/17

Answers to the additional questions below the report.

The most significant risk right now to the project is the PCB turnaround time. Cheaper solutions are based in China, which means longer shipping time. American solutions exist, but they will eat a large chunk of our budget. For now, we will probably use a Chinese service but pay for expedited delivery. The PCB has two parts: one is indispensable, since it attaches the Sparkfun processor with all sensors, but the other one can be worked around, if serious disruptions were to occur. The SparkFun PCB is the biggest lynchpin in the hardware system right now.

No changes were made to the design of the system this week.

No updates to the schedule this week.

Part A: how the product solution will meet a specified need with respect to considerations of public health, safety or welfare(Lin Zhan):

Our project aims to develop an add-on system for a saxophone to detect player errors and provide feedback. With respect to public health and safety, our project can have positive effects for saxophone players’ health. Self-practice can result in undetected errors and in the worst case cause physical damage to musicians. By identifying player errors and offering immediate feedback, our system encourages safer playing habits, thus promoting long-term physical health for saxophone players.
Regarding welfare, the system offers an economical alternative for saxophone players seeking instruction by minimizing the costs associated with formal lessons. It can enhance the overall performance of self-practicing.

 

Part B: how the product solution will meet a specified need with consideration of social factors.(Junrui Zhao):

By providing beginners with tools to track their progress and practice through a web app, our project caters to the needs of extended social groups, each with their distinct cultural and educational backgrounds. Specifically, this system lowers the entry barrier for saxophone beginners, offering enthusiasts the freedom to learn at their own pace. It opens up opportunities for self-directed learning and exploration, making the art of saxophone playing more accessible for all, regardless of their background or prior musical knowledge. This approach respects and supports diversity in learning styles and paces, fostering an inclusive environment that values individual growth within a societal context.

 

Part C: how the product solution will meet a specified need with consideration of economic factors(Jordan Li):

This project identifies a need of self-learning a woodwind instrument. As woodwind instruments are difficult to get started with, due to the large range of errors a beginner player can make, especially when player cannot identify these errors by themselves. It is impractical to have private lessons every day of the week, but practicing every day is the best way to improve instrument skills, so this product will be the player’s private instructors for when they cannot use private instructors. The project can also be modified to help the production of music for woodwind musicians, who may not have access to a keyboard as a MIDI input device, but can instead retrofit their own instrument to produce music electrically.

Posted on

Jordan’s Status Report for 2/17

This week, the main progress I made was to finalise the design of the saxophone attachments, as well as ordering parts. I also secured a saxophone for use during the projects from Kiltie Bands.

I based my design off this project: Jazz Hands: Hybrid Saxophone : 28 Steps (with Pictures) – Instructables.

I chose to use this design, because it is already a functional system for detecting fingerings, given that it is originally designed as a MIDI controller add-on. This seems to be a better system that using pressure sensors, as I will use his hardware design for fingering collection, but use software written by me to analyse the data collected from the sensors.

I am currently slightly behind schedule, as PCB orders did not go in last week. I will order the PCB in time for next Tuesday’s order batch, but other than that, I am on time.

I hope to finish the software component of the saxophone transcriber by next week, or at least have a buggy implementation. I am currently debating between two paths: one is to use MIDI controls, which uses the Sparkfun ESP32 to process the sensor data into MIDI data to feed to computer, or to just upload raw fingering data to the computer.

Posted on

Lin’s Status Report for 2/17

This week my main focus is to work on the pitch detection of the audio processing. I have transferred all my work from Matlab to Python, since it will be the primary language of our Web App’s backend. Currently, I am applying Short-time Fourier transform(STFT) to an input audio to get its frequency. Then I convert the pitch into MIDI notes and pair them with music notes. I tried several python libraries including Librosa and Scipy, which all deal with music and audio analysis. For now I’ve decided to use Librosa mainly since it’s been widely recommended by the StackOverflow users, but if things doesn’t work out later I’ll switch to Scipy.  I’m able to extract pitch and note from a 12tet diatonic music scale as shown in the graph below. 

My progress is on track this week. I wrote my code for music files within 10s and I plan to work on musics that are longer next week. Our design goal is to perform pitch detection to a roughly 60s music file so I will start to work on that next week. I will also try with some low SNR input files to test the pre-processing part of my code.

Posted on

Team Status Report for 2/10

Our team’s major concern for now is that parts may arrive later than expected. If the sensors and saxophone parts don’t arrive by next week, we will make some slight changes to our schedule by letting Jordan shift to helping the WebApp construction. Other than that there’s little risk since our goal this week is to get a clear view of our project and get things started.

We also updated our block diagram to include what our WebApp feedback will look like. We want to separate the feedback users may get from the WebApp into two major types, each has its own displaying. We will discuss more about what specifically “potential solutions” refer to next week.

Overall, we are in good track of our progress this week and every one has started to do their own job. The main design of our project remains the same, with some possible slight changes on labor division.

Posted on

Junrui’s status report for 2/10

Since I am in charge of the web app design and construction part of the project, this week I spent most of the time researching React and Django. I established the initial project setup, including configuring the development environment, figuring out best practices for integrating these frameworks, and drafting an initial architecture for our application. Additionally, I explored some essential libraries according to our project’s core functionalities. My goal for next week is diving deeper into developing the frontend components and aim to construct a basic version of the app’s frontend. My current progress remains on track with our planned schedule.