Dr. Damien's Development - The Xylophone Project V - Data Acquisition and Note Analysis

[DFGray]

Discussion has been excellent, as usual, and the project has multiple changes this week.

1. The main code has been encapsulated into a library.  With this, the file prefixes were removed, since they are no longer necessary.  The library handles namespacing.
2. The controls were all moved into the same subdirectory.
3. The default case was removed from the main VI loop to enhance debugging.
4. The note analysis object from NI Musical Instrument Tuner was added to the project for later use.
5. A new object encapsulating the data acquisition loop was added, along with a test.  It does not have all the set/get functions, but the core functionality is complete.

The data acquisition object is a queue based task handler.  See the test for an example of use.  It is a parallel loop to the main UI loop.  Note that the object reference is used in a single-element queue to allow the same object to be asynchronously accessed anywhere the queue is passed.  The queue reference as part of the object is an example of regression using objects.  I have never used this particular architecture before (single-element queue of object in the object), so it is an experiment.

Note that in two cases in the test, there is a wait for the data structures to properly initialize before proceeding.  This functionality should probably be added to the object itself as either methods or parts of the get/set/command methods.

The data acquisition is not yet used by the main code.  That will occur next week when we start integrating the objects into the main VI and turning on functionality.

Previous Installments

• Data Acquisition Concept
• GUI Concepts
• Specifications
• Core Architecture

Message Edited by DFGray on 03-23-2009 11:31 AM

[F._Schubert]

Thanks for long awaited new code.

But I frankly say, there is a bug magnet in there and if it would be my own code, I would start from scratch. Harsh words... I was thinking long about publishing these. If I'm wrong, as I'm not familiar with most of yours concepts at all, I apologize.

 I can queue a 'stop' in the CommandsQueue, while the ExecutionLoop is in running state, which just enqueus another 'run' direcetly afterwards.

I cant't find the post right now, but it was suggested not to use a queued state machine together with a producer. I normally use diffrent ways of command transmissin, one for the state to state transmission and the commands from 'outside' are checked in spcificstates ('idle').

On root of this is a skipped design phase. For such code I would do myself a first draft on paper and pen, followed by a state chart in MS-PPT or OpenOffice Draw, trying to follow uml standards (no link in english wikipedia). During/after coding the original state chart is updated. Maybe I would even draw an Sequence diagram (wikipedia).

All such documentation is placed as picture inside the vi as well as a path to the document.

Got a minor set of arichtecture specific issues as well: I prefere to have operations on the same wire in the same layer, so the destroy queues should be in the same layer as the create queues, all the sound vis in the same layer (nothing inside the 'ConfigureAquisition.vi).

Sorry for that harsh critics, but you're on the blue side.

Felix

[DFGray]

I have refactored the sound acquisition and eliminated the issues mentioned.  See the latest post.