Description
I just responded to discussion #235 with an idea to utilize my voiceover script to facilitate self-voicing of forms, but then it dawned on me that should probably be a new issue to begin with, to see if we could make sense out of just merging my code into nvgt completely, in some form or other, and then that would be available for use with the forms and whatever else. I for one use them heavily in my games with my hacked version of the bgt menu object.
The way it works, you can keep queueing individual phrases. Just set it up for the file format you'll use and the path for the sound files. You can just keep running the methods to add more, or you can do more than one file by using a preconfigured delimiter in your strings to have it split a single string into an array where it will try to play audio files for each item. If you don't have an exact match, it will try to spell it. It supports whole number processing up to like 18 digits and currently requires audio files for 0 through 19, then 20, 30, 40 etc to 90, hundred, thousand, million, billion, trillion, quadrillion and point.
It uses two sound objects in alternation to facilitate reducing the silence between files, with a configurable amount of time before end of current file to start the next.
It has ways to force spelling phrases. It can fall back on SAPI, using its own object or a supplied handle to one. You can force SAPI also, so that it will queue it in among the audio files deliberately. If you allow it, it will use SAPI to read phrases that you don't have sound files for instead of spelling.
It has several methods to run it. The normal way might be to call the speak method and then its builtin process method from the main loop that is currently running. It has its own loop you can run using the speakWait method, and supports a callback so you can continue running specific code while a speakWait is going.
It would not be terribly difficult to do alternative things like being able to do whole numbers in pairs, and play two digit recordings, like a file for 98 instead of playing 90 and then 8, etc. We just have to update my very old code.
So, if we're interested in integrating, we probably need to agree on the form it will take. Since I'm not so familiar with other inner workings of nvgt that might want or need to support relying on it, there could be issues to iron out about that. I can make a github repo and put the code there and then do a pull request, if I can figure out how to do that.
Do we want this built right in? Or does it make more sense to leave it as an add-on or plugin type thing that is just implemented using #include, or just keep it as a separate download, but the last option might leave missing out on capabilities to integrate with existing things like audio forms or menu classes.
I already uploaded the zip of it to discussion mentioned earlier, so I probably should not do it again here.
Let me know if interested. I don't know how to make this a discussion, if it needs to be such. Though, if we decide to try to implement, I think it needs to be an issue.