Well, the error, 4801, says "Invalid sound task refnum" (you can find out the Error by going to "Help", "Explain Error"). You define the Task Refnum in the Init State with Sound Input Configure, but you forgot to wire the Task Refnum to the lower Task Refnum Shift Register.
Here are some suggestions from my experience with State Machine-like VIs:
- My first State is almost always "Init" (sometimes I call it "Initialize"), and the last is almost always "Exit" (or "Finalize").
- I often have an "Idle" State, just hanging around (doing nothing, not even going to the next State) until I push the "Start" button.
- I usually use "Square Push Buttons" (like "OK" and "Stop", which by LabVIEW "default" conventions have the Latch When Release mechanical Action) and an Event Loop to Start and Stop my State Machine. To do this, I usually use a Design Pattern resembling the Queued Message Handler.
- Since the introduction of Channel Wires as a "hidden feature" in LabVIEW 2015, and a full feature since LabVIEW 2016, I've become a "nut" about Channel Wires and most of my major Projects contain one or more Channel Wire patterns I call the "Channel Message Handler", with a Messenger Channel replacing the Message Queue. Same idea, different implementation.
- I recommend that you name the "Record" State "Record" instead of "Read". I was initially confused by seeing that the "Read" State has a loop with "Sound File Write", which makes sense when doing recording, but is less intuitive if doing "reading". You want to strive for "intuitive-ness".
- Having a State called "Error", and checking for Errors at the end of the State Loop, will simplify your State code. You don't need to keep testing "Record", particularly if you add a second "Square" button called "Stop Recording" to signal the next State Transition. [Think about the controls on a Tape Recorder, though you might be too young to have seen such an ancient machine ...].
- You don't need a Wait inside the Sound Input Read loop. It will run exactly as fast as it gets data.
- You might consider making your data buffer a little smaller. The way you've configured recording (not a bad way to do so, in my opinion) is to record 100,000 samples at 22,050 samples/second, or roughly in 5-second "chunks". That means that if you push "Stop Recording" at 6 seconds, you'll get an extra 4 seconds of sound information you push the button. Is that what you want?
- Note that if you take my suggestion about a Stop Recording button, you need to think about what to do after you record a "chunk". A suggestion (off the top of my head) is to have an extra State called something like "Do Next Step", which would be either "Record" (another Chunk) or "Stop Recording" (which would close the file, turn off the Sound Input stuff).
- Do you want to automatically transition from "Stop Recording" to "Play Back"? Or do you want to have a "Play Back" button that starts the process?
- Suppose you expand your Button Set to include "Record", "Stop Recording", "Play Back", and "Quit".
- Do you see any "logical" reason to have both Play Back and Quit? What does this let you do, almost "for free"?
- Can you think how you would "force" a logical order of Button Presses (i.e. not allow "Stop Recording" unless "Recording" was active?
- Might an additional Indicator, say a red LED labelled "Recording", be useful, particularly with a "Latch When Released" Record Control?
Sorry I got so carried away. I sometimes can't resist putting on my "Professor Hat" (it looks a bit like a square piece of black cardboard, roughly 30 cm on a side, worn with the corners pointing front/back, left/right, and with a silly tassel handing down from the top) ...
Bob Schor
