Dr. Damien's Development - The Xylophone Project XIII - Documentation

[DFGray]

In this final installment, we add documentation to the project and clean up some issues. Here is what was changed.

• Add help button to the front panel.

• Add HTML help to the project.
• Fix menu issues on one dialog.
• Fix right-click issues.
• Fix note display.
• Sort notes by peak height, not frequency.

Documentation is very important to a finished product. While a well–designed GUI will make documentation less necessary, when a user runs into problems, a help button can often prevent a service call. Adding a help button to the current project involved quite a bit of straightforward coding, as well as creation of the documentation. Here are the steps that were necessary.

1. Add the help button to the front panel.
2. Create any screenshots needed.
3. Create the HTML documentation.
4. Add the help button reference to the XylFP.lib:XylophoneFP.lvclass data.
5. Update the class methods (Get, Set, rearrange front panel) with the new help button functions.
6. Add a task for showing the help.
7. Add an event to handle the help button press.
8. Add an event to handle the help keyboard shortcut.

Some of the top–level VIs needed a minor change to the appearance properties. In the VI Properties dialog, Window Appearance»Custom»Allow default run–time shortcut menus needs to be unchecked. On the same item, Show menu bar should also be unchecked.

The note display was always showing “A” due to a misuse of typecast. This has been fixed.

Under use, it became apparent that the first note shown should usually be the peak with the highest amplitude. The peaks are now sorted by amplitude before being displayed. For future consideration, the octave number of the note may be a nice enhancement (e.g. print “C5” instead of just “C”).

This is the final installment of this series. I will start a new thread for any updates to the code based on actual use. When this happens, the thread location will be posted below. As always, comments and suggestions are appreciated.

Next time, I will start a much shorter series on the art of launching independent top–level VIs from your main VI and why you would want to do this.

Previous Installments

• Data Acquisition Concept
• GUI Concepts
• Specifications
• Core Architecture
• Data Acquisition and Note Analysis
• Sound Acquisition Revisited
• Sound Analysis
• Configuration Dialog
• Calibration Dialog
• Font Issues and Front Panel Layout
• Configuration Save
• Build an Executable

[pallen]

This is great stuff!

Now I just need to write some code that will give me the free time to explore this project.  

[Neil.Pate]

Thanks for these series Damien,

I am still trying to get my head around some of the architecture decisions though 🙂

What is the logic behind the in place re-bundling in the Get VI attached? Is this some sort of performance trick to ensure the memory is reused? I would have thought just unbundling the bitDepth and returning it would have been sufficient?

[DFGray]

The InPlace node ensures that the only copy of the data which gets made is the single element being passed out.  An unbundle does not assure that.  I have started using the InPlace node instead of bundle/unbundle/index array etc. when I remember to do so.  It is often not necessary, but it is "safe."

[Neil.Pate]

---

DFGray wrote:
The InPlace node ensures that the only copy of the data which gets made is the single element being passed out.  An unbundle does not assure that.  I have started using the InPlace node instead of bundle/unbundle/index array etc. when I remember to do so.  It is often not necessary, but it is "safe."

---

Thats what I thought, it just looks a bit clumsy though using the inplace structure and the unbundle-rebundle with the same value.

If this is the best way to ensure no extra buffers get allocated, then we could do with a new primitive to effectively mimic the inplace bundle-rebundle 

[waldemar.hersacher]

---

Next time, I will start a much shorter series on the art of launching independent top–level VIs from your main VI and why you would want to do this.

---

 This is interesting for me. Some years ago I developed two version of a loader for top-level VIs. The one is searching through the folder structure for LLBs and VIs in them using naming conventions. The other uses a configuration file to determine the VIs to load. With the later I have control over the sequence in which the VIs are loaded and started.