This time, the sound analysis is implemented. The application is now functional, but lacks any run–time configuration. The following changes were made. The NoteCalculations class was converted to a singleton object through the use of a single-element queue. The same method was used previously for the AcquireSound class. This class still lacks a full set of accessor functions. These will be added when the configuration is implemented. The NoteCalculations class was expanded to detect multiple frequencies from a single input waveform. It still assumes an equal temperament scale. We may look at a different tuning when the first round of the application is finished. A pulse analysis loop was added to the main code. This is a queue driven state machine. It is queue driven to allow control from the main UI loop. One of the states is the actual data analysis loop. The analysis loop uses the NoteCalculations class and data from the AcquireSound loop to update the front panel. It was implemented directly on the main block diagram to take advantage of the huge performance benefits of using terminals versus VI server calls to update controls. The Run, Stop, and Exit cases of the main UI loop were updated to include control code for the pulse analysis loop. The application now consists of three parallel loops - UI, data collection, and data analysis. This is a fairly common use case. LabVIEW allows us to easily put these in different threads or different processors, depending on the capabilities of the target. This allows for efficient use of the computing resources. In this implementation, the acquisition and analysis loops are coordinated by the UI loop. Note that the analysis loop does send a Stop command to the UI loop in the event of error. While the acquisition loop could have done this, I prefer to put the response to the error in the consumer of the data. When calibration is implemented, there will be another consumer created, and it will have a different UI, with different error handling. The algorithms could also use some tweaking. For example, we are not interested in frequencies below 20Hz, since you can not hear them. These should be filtered out before display. As always, comments and suggestions are welcome and encouraged. Previous Installments Data Acquisition Concept GUI Concepts Specifications Core Architecture Data Acquisition and Note Analysis Sound Acquisition Revisited

LabVIEW

Dr. Damien's Development - The Xylophone Project VII - Sound Analysis

This time, the sound analysis is implemented. The application is now functional, but lacks any run–time configuration. The following changes were made.

The NoteCalculations class was converted to a singleton object through the use of a single-element queue. The same method was used previously for the AcquireSound class. This class still lacks a full set of accessor functions. These will be added when the configuration is implemented.
The NoteCalculations class was expanded to detect multiple frequencies from a single input waveform. It still assumes an equal temperament scale. We may look at a different tuning when the first round of the application is finished.
A pulse analysis loop was added to the main code. This is a queue driven state machine. It is queue driven to allow control from the main UI loop. One of the states is the actual data analysis loop. The analysis loop uses the NoteCalculations class and data from the AcquireSound loop to update the front panel. It was implemented directly on the main block diagram to take advantage of the huge performance benefits of using terminals versus VI server calls to update controls.
The Run, Stop, and Exit cases of the main UI loop were updated to include control code for the pulse analysis loop.

The application now consists of three parallel loops - UI, data collection, and data analysis. This is a fairly common use case. LabVIEW allows us to easily put these in different threads or different processors, depending on the capabilities of the target. This allows for efficient use of the computing resources. In this implementation, the acquisition and analysis loops are coordinated by the UI loop. Note that the analysis loop does send a Stop command to the UI loop in the event of error. While the acquisition loop could have done this, I prefer to put the response to the error in the consumer of the data. When calibration is implemented, there will be another consumer created, and it will have a different UI, with different error handling.

The algorithms could also use some tweaking. For example, we are not interested in frequencies below 20Hz, since you can not hear them. These should be filtered out before display.

As always, comments and suggestions are welcome and encouraged.

Previous Installments