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.

Posted on

Melina’s Status Report for 2/15/2025

EGG Hunt

  • Picked up all hardware components associated with the EGG EG2-PCX from Prof. Helou, along with the corresponding digital user manual
  • This includes a simple microphone which we plan to replace with a more sophisticated microphone

Ground-Truth Research

  • Annotated reading “Results from a pilot longitudinal study of electrolaryngographically derived closed quotient for adult male singers in training” (David Howard)
  • Annotated reading “The Physiology of Vocal Damping: Historical Overview and Descriptive Insights in Professional Singers” (Marco Fantini)
  • Annotated reading “Musical Theater and Opera Singing—Why So
    Different? A Study of Subglottal Pressure, Voice Source, and Formant Frequency Characteristics” (Eva Björkner)
  • Concluded that identifying a “proper” CQ would not be the most appropriate solution approach since the number of years in singing experience and genre would be required for such a metric. This data is limited at this time and would not be reliable for the purposes of our project
    • Because of this we have adjusted our scheduled tasks to reflect this change
      • Understand/identify improper CQ CANCELLED – we want to stray away from defining a universal truth for what a proper CQ is, instead focusing on helping vocalists track and understand their formant tuning
      • Inform about change in CQ ← changed from detect/warn about improper CQ
  • Proposed our project solution approach should shift from warning of “improper” CQ to providing more flexible analysis tools (2) for tracking CQ over time
    • Analysis tool 1: Allowing user to view their CQ at a given moment for a specific recording playback
    • Analysis tool 2: Providing user with a visual representation of an evaluation of their CQ range over time
      • This would be approached by asking the user to record a controlled vocal exercise, such as an octave warmup that covers their tessitura (comfortable vocal range)
      • The CQ ranges for these controlled (constant) exercises can be summarized visually over time as suggested by David Howard’s graph of idealized changes in CQ
    • Proposed our use case and solution approach should shift to focus on advanced vocalists in one genre, opera singers
      • CQ can be significantly more difficult to measure for untrained singers, in fact, David Howard had to completely throw out some data samples from untrained singers due to unreliable CQ measurements
      • Unreliable CQ measurements are detrimental to our project, as an incorrect analysis could mislead a vocalist to make unhealthy decisions
      • CQ has also been found to vary significantly with genre, and as of now, we only have guaranteed access to opera singers
    • Created a ground-truth metric
      • EGG passes calibration test with the laryngeal simulator before and after usage
        • This is handy dandy calibration hardware component that came with the EGG itself thanks to Prof. Helou
      • Use built-in Larynx Tracking & Signal-Strength indicators
      • CQ measurement must be at least 20% to be considered detected

Schedule

  • COMPLETED Acquired sensor
  • COMPLETED Create a “Ground-Truth” metric

My scheduled tasks are on time, and have been slightly adjusted as described above (I will reiterate below)

  • Understand/identify improper CQ CANCELLED – we want to stray away from defining a universal truth for what a proper CQ is, instead focusing on helping vocalists track and understand their formant tuning
  •  Inform about change in CQ ← changed from detect/warn about improper CQ

Next Steps

My goals for this next week include the following deliverables

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

Tyler’s Status Report for 2/15/2025

So far I have been able to get the electroglottograph to work, as well as learn about the larynx simulator attachment we got. For VoceVista however I am a little worried that once the trial version runs out and I do not input the key in time I will lose any files I upload into VoceVista if I can’t get the software key before the trial runs out. PhaseComp is the backup plan for me to be able to continue using the electroglottograph after the trial runs out and before I get VoceVista purchased.

For the larynx simulator it is able to mimic the larynx vibrations and is quite useful in guaranteeing that our electroglottograph is producing proper data.

Some things I want to focus on are getting feedback on the recordings I upload and understanding how to manipulate the closed quotient physically. I have meetings scheduled with opera singers as well to test out placements of the sensors to get the best data. Another thing I am not unsure of right now is how the microphone is incorporated with the electroglottograph and why it needs to be connected to the electroglottograph.

So far I at least on track, if not slightly ahead of schedule as I keep experimenting with VoceVista as well as the electroglottograph.

Posted on

Tyler’s Status Report for 2/8/2025

Voce Vista Usage

  • Voce Vista is a relatively expensive software, emailed them through their student discount application and hopefully will be approved to purchase a student discounted version for our project
  • Researched display of Voce Vista usage
    • In Voce Vista, CQ is displayed as a percentage in the analysis panel
    • The CQ is calculated based on the proportion of the glottal cycle where the vocal folds are closed

Purchasing components for EGG sensor

  • As we have not yet acquired the electroglottograph sensor I have not been able to purchase the parts yet
  • Professor Leah has a lot of the auxiliary items we will need, as soon as we acquire the EGG we need to take inventory to see what else we will need

Next weeks tasks

  • After acquiring the Electroglottograph, purchase a software to use with the sensor (Voce Vista if they give us a student discount otherwise PhaseComp)
  • Start measuring/utilizing Voce Vista to determine what type of data we can acquire from the EGG