Posted on

Team Status Report 2/22

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?

One of our risks right now is making sure that we will be ready for relevant builds in a reasonable timeframe. As Professor Sullivan mentioned during our meetings, it is important to order parts with significant time due to potential shipping delays. It will be important to place orders for our project early this week, presumably after having our meeting with our staff on Monday to confirm our feedback from the presentation, so that we can have our relevant hardware accessible. After the parts are ordered, we should make sure to actively track parts, including over spring break, to allow for pivoting if a part is heavily delayed.

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?

All of our existing design goals are aligned with what we presented at the design presentation. We did more heavily spec out our existing design decisions for the design presentation, including selecting our audio processing style, specific hardware decisions (e.g. using the Arduino Nano BLE), and lyric sourcing mechanisms from our potential options. We also prepared a more in depth GANTT chart than we had for the first presentation. However, we are prepared to use for potential feedback from our design presentation to adjust accordingly next week.

Posted on

Aleks Status Report 2/22

What did you personally accomplish this week on the project? Prove to the reader that you put sufficient effort into the project over the course of the week.
This week I spent time significant time on Sunday working on fine-tuning our design presentation slides. I also worked through one of the provided Spotify API tutorials, which should be useful in starting our development with Spotify. I did a bit of research into website scrapers as well, as I will be constructing one for our lyric retriever and I don’t have historical experience. Finally, I spent some time working on getting our design report started and understanding the relevant information that we will need to collect.
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?
Next week will probably be mostly spent working collaboratively with my team continuing to work on our design report. With any additional time, I hope to do expand my work with Spotify API to provide relevant proof of concept for integration with Hugo’s audio processing.

Posted on

Kiera’s Status Report for 2/22

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week.

This week I spent a significant amount of time preparing and rehearsing to give our design presentation. Additionally, I planned out more of the specifics for our microphone and accelerometer system. After doing research on different microcontrollers that we could potentially use I came to the conclusion that the Arduino Nano BLE would be the best fit for our design requirements. The built in accelerometer and bluetooth capability allow for our design to be more compact and mobile. 

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?

By next week I hope to have placed orders for the required parts and to have a fully fleshed out plan for the casing of the microphone. 

Posted on

D1 Team Status Report 2/15

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?

Our biggest risks at the moment are coming from our signal processing for scoring and from our ability to do vocal removal with low latency. Scoring is risky because as we have recently moved away from pitch detection, we are now developing new ideas for metrics and if we are not able to select one and start testing it as soon as possible, we leave a risk of missing out on a major component of our gamification. For our vocal removal, we have confirmed that it is possible with low latency via software, but we still need this to become a hardware system ideally. Both risks are being managed by quick decision making, as we are finalizing design choices right now and are hoping to be able to quickly get to a testing phase and prototype these pieces as soon as possible. As far as contingency, for our scoring, we have a range of options including some extremely easy (but unideal) work arounds. For the vocal removal, there is always the option to use an AI model to do the work which is proven to be possible.

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?

The primary change is switching from a bandpass / bandstop filter to the subtraction method taking advantage of stereo output. There is not much as far as surface level cost, but this does limit our potential music library to only songs that exist in stereo format. It will simply require a small check with the Spotify API to verify before allowing the user to confirm.

 

Additional Questions:

Part A (Written by Kiera): JustPerform is designed to promote the psychological well being of our users by creating a simple and affordable at home karaoke experience. Self expression through singing and dancing can be an effective way of alleviating stress and improving your mental health. Our product makes this possible for those who may not be able to afford to go to a karaoke venue.
Part B (Written by Aleks): JustPerform promotes social interactions by providing a fun group experience for at-home events. Music and dance are universal cultural expressions, and by allowing users to convert their personal music libraries into karaoke tracks, JustPerform allows for greater personalization and culture, accommodating different musical tastes and traditions. Additionally, the incorporation of dancing produces physical activity, promoting health and well-being.
Part C (Written by Hugo):
From an economic perspective, JustPerform presents an affordable alternative to traditional karaoke systems, combining all of the facets of the karaoke experience into one product. Additionally, by allowing the user to use their own library, there is no limitation of traditional karaoke machines which are limited by the preloaded library they come with. Additionally, its multi-functionality appeals to a broad market, including households, party venues, etc. , increasing demand and potential revenue streams
Posted on

Hugo’s Status Report 2/15

Continuing on where I left off last week, this week I spent my time looking into the specific methods for implementing the system. Because I am our primary audio processing lead, my work revolved around fleshing out not only systems for vocal removal, but also how generally getting the full outline for how our data is being passed around and what kind of processing we need to do. First, after our proposal presentation, we had a slight change of path with regards to how we want to do scoring for our game. Originally, we had intended to work with pitch detection but now wanted to find something that more accurately captured the karaoke experience for the average user. We came up with a series of new metrics and strategies, and are continuing to analyze and pick a specific plan. Then, I took time to investigate the vocal removal aspect. Because this is currently such a fundamental part of the project it is imperative that this works as expected. I used matlab to do some tests by passing through audio files to see the effects of our original bandpass and bandstop filtering idea. In the end, this was not effective. Although the bandpass could kind of get a weak signal that almost isolated the vocal (often leaving in percussion), the bandstop filter was next to useless at removing the vocals from the backing track. So, I moved on to testing methods that take advantage of audio in stereo format to cancel out the vocals by subtracting the left and right channels. In the end, this did provide favorable results while still allowing us to work with a hardware system as we had originally hoped. Then I took time to read into the actual wiring and built up a design for splitting the two audio channels, passing through our subtractor, adding in the microphone input, and outputting to a speaker. I also took some time to look at possible speaker options and assessed whether this was a part that we wanted to allocate substantial amount of the budget to, as it is crucial that the sound quality is high for the product to reach our user requirements.

Posted on

Aleks’ Status Report 2/15

This week, I focused on working through our design requirements with our group. I participated in multiple group sessions to brainstorm the best solutions and both ask for and provide feedback on our individual project research areas. I continued my research into the Spotify API to ensure it met our updated requirements. I also did research into discovering the best strategy to retrieve lyrics for our application. I spent time researching and evaluating multiple APIs, web resources, and tools for accuracy and availability. We also got feedback that our GANTT chart needed improvement. I created a true GANTT chart and updated the tasks and timeline to be more fully fleshed out and aligned with our new design decisions. I also spent substantial time working on our presentation slides and going through gradual iteration and revision with my group. Next week, I hope to spend a bit of time actually building with our resources, then I will focus on our design report, taking into account any feedback from our presentation.

Posted on

Kiera’s Status Report for 2/15

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week.

This week I continued to work through and finalize the design of the microphone and accelerometer system. I spent time researching tradeoffs of different microcontrollers based on our design goals of having it fit on the microphone, having easy communication with the software, not adding too much latency to the system, and not being too expensive. Additionally, I looked into the option of using camera vision instead of an accelerometer to track the user’s motion but decided that the accelerometer system fits better with our design goals and CV will be a contingency plan. 

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?

By next week I hope to have tested parts of the accelerometer system using spare components and to have further fleshed out the design in the report.

Posted on

Team Status Report for 2/8

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 we are currently faced with is making the wrong choices in our early design stages. To manage this risk, we have each spent the week researching the tradeoffs of the design choices we each need to make in our portions of the project. For the larger technical challenges of our project we plan to test our proposed solutions to them early in case they do not work out the way we expected. Our primary contingency plan consists of having planned out alternatives ahead of time in the case of a fall-through with our current design.

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?

The main change made to our existing design was the connections between all of the components. Originally, we planned to have the microphone send motion and audio data to the computer while also sending the audio data straight to the speaker. We decided this would be an awkward wiring system for the user and instead opted to send everything through the computer, especially as our original design included some filtering of the microphone signal which we deemed unnecessary after research. We also previously planned on using a hardware filter to separate the vocal from the backing track in the speaker but decided this would be more achievable using software.

Posted on

Aleks’ Status Report 2/8

This weekend, I prepared to present our project proposal presentation. During the week, I looked more deeply into Spotify API to analyze exact functionalities that would be useful and make sure all of our use cases for their data followed their usage guidelines. I found some interesting audio analysis features that are notated as deprecated, but I want to do more research into. I also set up our GitHub repository and initialized the Django Webapp so I can do some work through Spotify’s tutorials next week to make sure we can load the music appropriately. I also did some review and practice coding web applications to brush up on my skills. Additionally, I met with my team to brainstorm through some of our system design decisions based off of presentation feedback. Next week, I plan to dig into our design decisions next week to determine our best design plans. I will ensure Spotify works for our use cases and look into best methods for procuring our lyrics, especially using a potential fix that a student in our section (Maya Doshi) told us could be useful.