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.

Team’s Status Report for 2/24

The most significant risk now is that all of us are slightly behind schedule, since we all have midterms coming and assignments due. To manage this risk, we will discuss, revise our plan and work together in next week’s mandatory lab to keep up with the schedule as quickly as possible.

An existing change made to our design is on the audio processing side. After the presentation on Wednesday, we received some suggestions from instructors about the rhythm processor. We initially planned to merely use a pitch detector when processing the audio, but as we should be dealing with rhythms instead of several single notes, a rhythm processor is definitely needed. So Lin is researching on the rhythm processor by researching papers and learning from previous projects now, and other teammates will also help if there are some problems implementing it.

an updated schedule is below:

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.

Junrui’s Status Report for 2/24

This week I was busy preparing exams and finishing assignments, so I had little time working on the project. I have discussed with my teammates about this.

I am currently a bit off track, so my next week’s goal is to continue with the existing work and quickly catch up.

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.

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.

Junrui’s Status Report for 2/17

This week my primary focus is to design the web app interface, decide on the functionalities it should offer and set up its structural framework. I have outlined a few pages in our app, including user authentication, user statistics(where a user can check history error rate of each practice song),  basic knowledge about learning saxophone, practice and feedback. Here’s a block diagram that shows my design for our web app, 

Currently, I’ve managed to implement a basic user authentication system that operates locally.  Additionally, I’ve completed the navigational framework between pages, although the content on those pages is still in the placeholder stage. 

My progress is on track this week. Next week I intend to focus on developing the content for our practice and feedback pages, aiming to dynamically display text based on one or two hardcoded inputs. I also plan to begin collecting saxophone fingering charts and images for various notes. Hopefully I can also get the input diagram completed by the end of next week. Below is an example sketch illustrating my envisioned layout for this page: 

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.

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.

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.