Posted on

Melina’s Status Report for 3/1/2025

Schedule

Official Project Management Schedule Updates

  • COMPLETE Design Report
  • IN PROGRESS Pitch Analysis
  • NOT STARTED Match Microphone Data to EGG

Personal Task Updates

  • DONE Draft Design Review Report with the team
  • DONE Ensure the team has a repository set up along with agreement on code style/organizational expectations
  • DOING Draft code for pitch analysis
  • TODO Propose modification to Pitch Analysis Testing

My tasks are on time, and given that nothing new was currently scheduled, I have Week 8 to complete pitch analysis.

Pitch Analysis

An initial attempt has been made at utilizing Librosa for pitch analysis. I learned how to load an audio file and extract basic information such as tempo, frequencies and their magnitudes. The current issue is that the pitch detection algorithm outputs a lot of frequencies, with some that appear to be noise. Overall extracting frequencies at the correct times is difficult, however, after reading Tyler’s updates, I saw that Voce Vista may already output the frequencies in a cleaner manner. This would help the algorithm more accurately map those frequencies to a note based on a standardized chart. The algorithm will have to take into account that there is some natural variance in pitch for the human voice compared to instruments. For example, the standardized chart marks G4 at 392 Hz and G4# at 415.3. An appropriate range has to be considered to distinguish adjacent notes. I’m currently thinking of approaching this by providing some slack in the range of frequencies that map to a note. This means our testing would likely be modified to include having a vocalist sing a series of notes, such as “Happy Birthday” and have the vocal coach verify that that the pitch detected agrees with their perception of the pitch for 90% of the notes sung. Proposing this modification for testing to the team has been noted as a new personal task.

Posted on

Tyler’s Status Report 3/1/2025

Not a lot was accomplished the week before spring break, as I primarily focused my attention on working on the design report but I was able to spend a couple hours working through VoceVista. Right now I am trying to think of the best way to transfer the information we get from VoceVista into our software component. VoceVista can output the files into an excel sheet or an image and it has a lot of different capablities of different data we can output. Not only can we output all of the EGG data we can also output pitch as well as statistic results. Now, I need to decide on how to export the data with Melina and Susanna to decide what is the easiest way for them to process this data as well as decide easy ways to transfer the audio recordings from VoceVista out as well.

Progress is mostly on schedule, I feel like I could be a little bit more familiar with the VoceVista interface but I will get better as the semester goes on. Focus now will be finding ways to output the VoceVista files into useable information.

Posted on

Team Status Report for 3/1/2025

Sensor Adhesive

We had previously thought that the electrode gel, which is applied to the neck sensors before the sensors are fixed to the neck, might function as an adhesive. However, the electrode gel serves as an aid in conductivity, and doesn’t have adhesive properites. Established methods for attaching the sensors include a neck band, tape, and simply having the user hold the sensors up physically. Holding the sensors is obviously cumbersome and a violation of our use-case requirement of comfortability. Discussing this issue with our vocalists, we confirmed that a neck band would also be uncomfortable and could impede movements necessary for singing freely. As a result, we are purchasing some specifically designed skin-adhesive tape to tape the sensors in place, which will hopefully maximize both comfort and secure sensor placement.

Schedule for SoM Meetings

We determined a schedule for our meetings with our School of Music partners following break. We’ll start with a week of practicing using the electroglottograph with vocalist users, then start gathering weekly warmup data so that our final presentation can include the data over time for five weeks for two vocalists. At the same time, we’ll start experimenting with repertoire recording, likely with piano accompaniment, in week 10.

Future Test Users

While we have the opportunity to work with two vocalists in the School of Music (a soprano and a mezzo-soprano), our hope is to ultimately test our product with a larger number of vocalists to get more meaningful data for our user feedback survey. This will depend on whether or not more vocalists are willing to sign up for the music course we’re currently a part of. There’s also the question of whether we’d be interested in expanding the target audience of the product slightly to include singers who are trained, but aren’t necessarily vocal majors or opera singers. Even though our current use case is more specific, other singers might still be able to offer feedback for things like the ease of setting up the device. This decision will depend largely on whether or not more vocalists are willing to join the class.

Data Privacy

One issue we were considering is that of securing user data, since some users might consider their CQ data or vocal recordings to be private. However, with the advice of Tom and Fiona, we’ve concluded that this actually falls outside of our use case requirements: like any recording software, this application is meant to be used on personal devices, or in a controlled lab setting, and all the data is stored locally. As a result, we will not be worrying about the encryption of user data for our application.

Product Solution Meeting a Specified Need

A was written by Melina, B was written by Tyler, C was written by Susanna

Section A

Our Product Solution considers global factors by including users who are not in academia or do not consider themselves technologically savvy. Although our product utilizes specialized hardware and software, our solution includes a dedicated setup page that aims to facilitate the use of these technologies for users who will be assumed to have no prior experience with them. The feature pages of the app will also include more information about how to interpret the CQ in the context of a controlled exercise time series analysis and a distinct repertoire. We have also considered that the accessibility to our product beyond Pittsburgh is limited by the purchase of EGG hardware and Voce Vista software. Our product solution makes use of a shared lab that can be duplicated with these purchases for any other local region.

Section B

Some of the cultural factors our product solution take into account is how opera singers normally sing and what the accepted practice is. We spent a lot of time conducting research on the vocal pedagogy of opera singers to ensure that when we output data it does not contradict what the user’s vocal coach instructs them to do. On top of that, we have taken into account that it is usually taboo to try and get a singer to change the form of how they sing and have decided to instead just output the information in a useful way so that the opera singer can decide whether or not to make changes, instead of originally suggesting form changes for the opera singer.

Section C

The physical components used in this product (electroglottograph, connector cables, microphone, etc) were created by extracting materials from natural sources. While the overall goal of the project is not directly related to environmental concerns, the overall impact of the product can be minimized by using durable and reusable components where possible. Notably, we found a preexisting electroglottograph to borrow rather than buying or building our own. This certainly saved us considerable cost and effort, but is also notable for significantly reducing the amount of new material that went into building the project. While we did need to purchase a microphone new, we purchased a high-quality model that will be able to be reused in future projects.

Posted on

Susanna’s Status Report for 3/1/2025

Well, I significantly overestimated what my bandwidth would be this week before spring break. I spent a lot of time working on our design report, and given that my spring break travel started on Thursday, I didn’t end up having time for much else. 

MVC vs MVVM

One thing that I did more research into this week was the model for our software architecture. Originally, I had conceived of our backend as MVC (Model View Controller) architecture due to my familiarity with this paradigm from my experience developing web applications. However, looking into it a bit more, it turns out that the standard for desktop applications is MVVM (Model View Viewmodel).

Basically, MVVM introduces complete separation of concerns between the GUI (View) and the database and program logic (Model) with the Viewmodel acting as a mediator. This will make it easy for us to develop these elements in separation. Plus, it’s a reactive architecture: the Viewmodel automatically responds to changes in the Model, and likewise, the View responds to changes in the Viewmodel, which will be useful for real-time updating, like the animation of the cursor that scrolls over the music. MVC is a similar paradigm, but less strictly enforced, and more suitable to web development. Of course, for either paradigm, it’s up to us how strict we’re going to be, and there’s always options to customize. Tentatively, I think this will be a helpful general framework for us to follow.

Last Week’s Goals Revisited

  • Write my parts for the Design Review report – COMPLETE
  • Research & make a decision about DearPyGUI (ASAP) – COMPLETE
    •  Given the sorts of data analytics we will need in the application, and our desire for a flexible and engaging user interface, we decided that DPG is our best option for
  • Better documentation for code – IN PROGRESS 
    • started README file, but haven’t tested it on other devices
  • Record Screen File Saving – NOT STARTED
  • (Optional) Playback Screen Upgrades – NOT STARTED

Goals For Next Week

  • Better documentation for code
    • Finish README file for setting up dependencies on different OS
  • Re-implement basic menu, record screen, and playback in DearPyGui
  • Record Screen
    • User can choose to either save/discard a recording instead of auto-saving
    • User can customize naming a recording upon saving
  • (Optional) Playback Screen
    • Add cursor that moves while playing
    • Let user drag cursor to various points in the playback
    • Add separation of signal into rows + scrolling

 

Posted on

Susanna’s Status Report for 2/22/25

Week Goals Revisited

  • Implement the basic MVC application with homepage
    • COMPLETE – It’s not much to look at, but the homepage exists:

  • Create GitHub repo
    • IN PROGRESS – I created a repo, but still need to update the README with instructions for using the app on different operating systems (and testing this with my teammates to make sure it actually works)
  • Create baseline audio recording page functionality
    • COMPLETE – I created a simple page that can record an audio signal. However, given that we know now that the microphone signal will be going through the EGG directly, I don’t think this version will be used in the final product, though it’s useful for testing now (instead, I think that the audio signal will come from VoceVista– though, the record page could still be useful for giving the singer visual/auditory cues to go through given warmups)
  • Create baseline audio playback page functionality 
    • COMPLETE (ish?) – I didn’t exactly give a definition for “baseline” here, but I do have a basic version of the page, including a visual of the amplitude of the audio waveform. There’s still some things left to do, though: I’ll need to splice the audio signal into rows, allowing the user to scroll through a longer recording and syncing more seamlessly once we add the EGG signal. I also haven’t yet gotten the cursor to work (showing where the user is in playback)

  • Help Melina with creating wireframes for application
    • COMPLETE – we have designed basic versions of the main application views, which was very helpful for clarifying some things in the design (namely, the separation of recording pages from analytic pages, and we’re planning to have separate recording views for recording repertoire (the original vision) and for recording guided warmups (which ends up being more useful for formally tracking CQ over time)). Below, for example, is a view of the general idea for the CQ warmup page.

Overall, I’m pleased with this progress, as it gives us some good ground for developing the app further, and I’m on track with what we have on the schedule.

DearPyGUI

As noted in our team update, we’re seriously considering switching frameworks from TKinter to DearPyGUI for the sake of its more seamless mechanisms for data visualization. I’m a bit torn on this, because TKinter has very good documentation and is more of a standard choice– plus, I’ve already spent some time learning about it and getting the application started. On the other hand, I don’t want to be knee-deep into a TKinter application and suddenly realize that it doesn’t give us the functionality that we need– and I’d love to have a more modern look and feel for our app, though it’s not a top priority.

Goals for Next Week

  • Write my parts for the Design Review report
  • Research & make a decision about DearPyGUI (ASAP)
    • Copy a sample DearPyGUI app and gauge its intuitiveness
    • Determine a more specific list of plots that we’d like to have for our final project, and see if there’s anything that DearPyGUI clearly does better
    • Rewrite what I’ve done so far if we do decide to switch
  • Better documentation for code
    • README file for setting up dependencies on different OS
    • Better code comments
    • Better MVP formalization
  • Record Screen
    • User can choose to either save/discard a recording instead of auto-saving
    • User can customize naming a recording upon saving
  • (Optional) Playback Screen (if we do switch to DearPyGUI, I don’t think I’ll have time for this)
    • Add cursor that moves while playing
    • Let user drag cursor to various points in the playback
    • Add separation of signal into rows + scrolling
Posted on

Tyler’s Status Report 2/22/2025

I have been able to get the audio files into VoceVista and use the electroglottograph with VoceVista as well as display the microphone and electroglottograph audio together. I want to better determine how to export these files into other applications so that Melina and Susanna can use it in their programs and determine what type of outputs I can transfer out of VoceVista. Another issue I am encountering right now is getting a clear signal and I am trying to determine what are good practices when applying the sensors as well as where to apply the sensors in order to get clear signal waves.

I believe I am still on time, I won’t have too much time this week due to my schedule but I feel relatively confident in my VoceVista skills to be able to move on towards the next steps. This week I want to be able to sort of scout through VoceVista to find anything else that might be useful for our project outside of what I know currently.

 

Posted on

Team Status Report for 2/22/2025

VoceVista

This week, we got our request approved for purchasing VoceVista, and began to learn how to use it. The one lingering concern is that we only have one copy of VoceVista at present, in use on Tyler’s laptop. At the moment, we think that this will be sufficient for our purposes: Tyler can use his copy of VoceVista to generate output files from tests with the EGG, then send these files to Melina and Susanna to be used as test inputs as they develop code. Additionally, there’s a 1-month trial version that we can use at key times if necessary.

However, we’re planning to reassess as the project develops, as it may become necessary for Melina, in particular, to have more direct access to VoceVista while she works on the backend. Additionally, we don’t currently have any major purchases in mind that will be necessary for the remainder of the project, so a second VoceVista access code might be a good investment if no more pressing costs come up. In the coming weeks, we’ll be paying attention to any potential for further costs, as well as the extent that a single access to VoceVista is a burden.

DearPyGUI

While TKinter is a widely-used and versatile framework for Python app-building, we’ve been discussing other options that are more versatile for the plotting functionality that our app will require. Specifically, DearPyGUI has both a powerful graphic display and strong backend functionalities that tie in closely with the frontend graphics. Though Susanna has made a start on working on the TKinter app, it’s not too late to change the framework, but if we’re going to do so we ought to do it as soon as possible. We will be testing DearPyGUI and making an assessment by the end of the week.

Pitch Analysis

We realized that the tasks in our schedule were a bit out of order– in particular, the pitch analysis task occurred before we received our microphone to record audio. As we have now acquired our microphone and cable, we bumped our pitch analysis task to next week.

Posted on

Melina’s Status Report for 2/22/2025

Schedule

Official Project Management Schedule Updates

  • COMPLETED Design Presentation
  • IN PROGRESS Design Report
  • IN PROGRESS Pitch Analysis

My progress from goals from last week. Any DOING tasks will be rolled over as goals for next week.

  • DONE Present Design Review Slides
  • DONE Drafting wireframes for the frontend with feedback from Susanna
  • DOING BLOCKED Draft code for pitch analysis
  • DOING Draft Design Review Report with the team
  • DOING Ensure the team has a repository set up along with agreement on code style/organizational expectations

Most of these tasks were ahead of schedule, so we’re not worried about them being in progress. The official schedule would suggest Pitch Analysis should have been done this week, but this was misleading; I will elaborate below in Pitch Analysis.

Design Report

We are in the process of drafting the Design Report.

I have shared a Google Doc with sections for us to draft content in, as well as setting up the latex file we ultimately use to format our final design report.

I have drafted a revised block diagram that integrates our hardware and software systems. This reflects a proposal I made to the team that changes our software design; I propose we use Dear PyGUI instead of TKinter. This tool is well documented and provides more

DRAFT EGGceptional Vocals Block Diagram

This diagram reflects a proposal I made to the team that modifies our software design; I propose we use Dear PyGUI instead of TKinter. This toolkit is well documented and provides more support for app development and data plotting which is an important aspect of our project for visualizing users’ CQ time series analysis.

I am also currently drafting the following sections

  • Design Requirements
  • Software Design Specification or Subsystem
  • Tests for Use-Case Specification Software
  • Related Work

Pitch Analysis

I realized our scheduling of “Pitch Analysis” was slightly out of order since it should be after we have a processed microphone signal to work with. Tyler very recently acquired the full-version authentication code for VoceVista, so as soon as  Tyler sends me at least 1 digital audio signal recording, this task will be considered unblocked and I can continue working on it this upcoming week.

Git Repository

I confirmed with Fiona that we can set up our own repository, and prepared a discussion with the team about repository management expectations and code style. This discussion will be brought up on Wednesday since we are currently focusing on drafting the Design Report. By Wednesday I will at least have the repository created so it’s ready to clone.

Posted on

Susanna’s Status Report for 2/15/2025

This week, I learned more about the EGG and its setup and ground truth research methods with the rest of the term. I also continued to work on building my Tkinter skills and think about the frames needed for the desktop app.

School of Music Conversations

Before getting into technical stuff, I wanted to note some new thoughts from conversations with School of Music collaborators, particularly with regards to options for sheet music syncing and microphone recording. One thing that we hadn’t thought much about is the need of an accompanist to help our singers to stay on key, if we’re doing anything beyond basic warmups (where it would be relatively easy to play ascending/descending starting notes). Fortunately, there’s accompanists in the SoM who would be willing to help with this. I suppose one of the possible complications could be getting a clear microphone signal when multiple ins. However, a strong possible advantage of this setup is that it might actually help us with sheet music syncing– if the accompanist uses a MIDI keyboard, the direct MIDI input will be comparatively easy to match to the MusicXML file. This would be a helpful way of syncing to sheet music without forcing our vocalists to stay on a super strict tempo.

Speaking of the tempo issue, our vocalists expressed mixed feelings about singing to a metronome. On the one hand, both of them appreciate, to an extent, the opportunity to do more practice with a metronome. However, they also worry about having the room to properly and fully form notes as they sing, which (as I understand it) could be impeded by an overly rushed/strict tempo. I think we could definitely sacrifice some level of matching accuracy to give some leeway here. Also worth noting that both vocalists strongly preferred the idea of an audible metronome to a visual one. However, I’ve come to tentatively prefer the MIDI idea (if that ends up being possible) given that an accompanist will be necessary in any case, and adding an accompanist would make the metronome option more complicated besides.

That being said, we’ve decided that sheet music syncing is a stretch goal for now– even though, as a musician, I think this will be one of the most useful extra things we can do, and I’d definitely like to prioritize it if possible! However, it is secondary to simply recording and displaying the EGG/audio signals themselves, so I’m going to put a pin on this rabbithole until I get more of the basics done.

Tkinter Learning

I’d never used Tkinter before, so I started by following parts of this Real Python tutorial to get started, with particular focus on learning about frame widgets (which I plan to use for switching between windows in the application). 

Based on my experience with building web applications, and given the number of frames in the application, I decided to follow a Model-View-Controller (MVC) paradigm for the desktop app to keep things organized. After some trial-and-error, I worked through this tutorial by Nazmul Ahsan to learn how this can be done in Tkinter. 

Progress Status

I am still on schedule with my parts of the project according to the plan. That said, I haven’t really made progress in the code for the application itself, and I think I ought to have set apart more explicit time in the schedule for simply getting to know the technologies that I’m using for this project. 

Goals for Next Week

  • Implement the basic MVC application with homepage
  • Create GitHub repo
  • Create baseline audio recording page functionality
  • Create baseline audio playback page functionality (with room for adding a future EGG signal)
  • Help Melina with creating wireframes for application
Posted on

Team Status Report 2/15/2025

 

Some risks that could jeopardize our project are if we are unable to get our  VoceVista software before our trial period is over. A contingency plan we have in case is to utilize a different software or transfer over any tools we used and have another device activate VoceVista to use for a month in order to guarantee that we will have VoceVista over the 6 week period before we can purchase it.

No changes were made to any system design, however we did adjust some key concepts of our use-case and solution approach:

  • The use case has shifted to explicitly consider a shared lab space
  • The use case has narrowed down from all singers to advanced vocalists
  • The use case requirement of customizability is now primarily associated with tessitura
  • The solution approach has shifted to focus on opera singers
  • The solution approach has shifted to inform the user of significant changes in CQ rather than warning of an “improper” CQ

 

Tyler did Part A, Susanna Part B, Melina Part C

Part A: … with respect to considerations of public health, safety or welfare. Note: The term ‘health’ refers to a state of well-being of people in both a physiological and psychological sense. ‘Safety’ is the absence of hazards and/or physical harm to persons. The term ‘welfare’ relates to the provision of the basic needs of people.

Our product will take into account public health and safety while singing by allowing users to become more aware of their laryngeal closed quotient by using an electroglottograph to measure out the user’s closed quotient. This can help mitigate vocal strain as it can provide information if the larynx is too closed while singing or too open. On top of that, we are making sure that all we are doing is outputting measurable data from singing instead of just providing feedback, so the singer can review and determine if the changes provided are necessary or not to their style of singing so that way they do not make any corrections that damage their ability to sing.

Part B: … with consideration of social factors. Social factors relate to extended social groups having distinctive cultural, social, political, and/or economic organizations. They have importance to how people relate to each other and organize around social interests.

Singing practices and techniques are highly varied and culturally contingent. Additionally, singers with different levels of experience will have different needs. More experienced singers might already be aware of the larynx and how it functions, and will appreciate more detailed analysis of their voice. More beginner singers might need a more basic setup as they’re experimenting with this part of their voice for the first time. Thus, different demographics will have significantly different wants and needs from a vocal training application of this nature.

Unfortunately, it’s not possible for our application to account for every style or tradition due to the sheer scale of the endeavor– plus, the world of electroglottography research is small, and the majority of data is related to the Western Classical Tradition. For our project specifically, we have the opportunity to work with trained opera singers in the School of Music, so we are going to focus primarily on this demographic. Additionally, we will be working in a pedagogical/lab setting. Unfortunately, this is a small group of potential users. Future versions of this application could prioritize working on a more inclusive use case, especially when it comes to giving feedback to newer singers.

Part C: … with consideration of economic factors. Economic factors are those relating to the system of production, distribution, and consumption of goods and services.

Our product solution will take into consideration economic factors by making use of a lab space as an approach to high cost. The product will include numerous components that can be difficult for an individual vocalist to purchase, including the EGG ($850), VoceVista ($400), and a high quality microphone ($150).  In total our product would be expected to cost an individual user about $1400 which is economically inaccessible to many, and therefore inadequate for traditional commercial production. To address this, our project solution will be designed with a shared lab space as part of our use case. This means our project will intend for more than one advanced vocalist/vocal coach to utilize the same  app and associated hardware housed in a shared lab space. Our implementation will realize this through the use of a login mechanism such as password authentication that allows users to share expensive resources while only accessing data that belongs to the logged-in user. We will assume that the lab will have sufficient resources to store the users’ data since our app is designed to run locally as opposed to a web app on a server, and we understand that this has security implications that we will need to consider.