Slee The Sloth
In speech recognition, on the setup menu I would like to be able to run a script before the Speech Phrase is spoken and one after Speech Phrase is spoken.
Secondly on the same page. It would be great to have a search box to search The Phrase list that trips the script. This would make it much easer to find specific entrees.
Upgrade to ARC Pro
Unleash your creativity with the power of easy robot programming using Synthiam ARC Pro
Obviously after the speech phrase a script can run. But how would a script know to run before you ever speak anything? If there was a giant spider about to fall on your head to worn you I would need to speak first and say, "Giant Spider, better move!" before you react, correct?
As far as how to know if a phrase is a bought to be spoken, It appears to me ( and I may be wrong) but it looks like an IF statement is used to check each Phrase then starting the a prorate script. If that's the case then the command to run a start script right before the Phrase script is triggered and then an END script right after it has been triggered.
Or in the speech command scrips, add a Cheat Sheet command to pause or disable the speech commands at the top of your scripts so nothing else can be heard while the script is running until the "Enable Speech" command phrase is used again. I can't think of anything else I'm afraid.
Yes that is a familiar problem when the robot hears and talks to itself, there are a couple of my videos with "RedBender" where he comically does just that. My solution was just like RichardR said, script the pause and un-pause of the speech control.
Yes, the use of cheat sheets to pause the speech recognition control I mentioned in post #5 is something I use in all of my speech recognition scripts as I have I countered the same problems, and it works great.
It's a good idea though about having a search box to easily look for commands, especially when you have about 400/500 of them.
One of my main programs is called "RPS Program". In RPS Program is a script called "RPS Main". RPS Main contains all the phrase responses associated with the RPS Program. The individual scripts in the Speech Recognition module for the individual phrases to be recognized are usually very short. Just the setting of some variables and then the calling of the RPS Main script, similar to that shown above. This centralizes the individual scripts for the Speech Recognition module. And that has the advantage of easy searching through them to find (Ctrl-F) any one you need to look at or change by a simple search of the RPS Main script. You don't need to look at every script individually in the Speech Recognition module to find what you want. Same when you want to do a Search and Replace (Ctrl-H).
Additionally, RPS Main does the usual housekeeping associated with the phrases response scripts. Such as turning the Pause Speech off and back on. Rather than doing that every time for every script, it's only done once at the beginning and end of the RPS Main script. If there are cases when you don't want that, you can declare variables to handle those situations with IF statements in RPS Main, setting them in the Speech Recognition scripts that need them. Generally, anything that is done in your software again and again can be handled centrally this way. I even route all my speaking functions through a central routine which handles things such as routing of the speech to either the PC speakers or the EZ-B Speaker or setting the volume (I like to boost the volume going to the EZ-B speaker, then set it back after the phrase is spoken). I actually go a step farther and route some things through central processing script(s) in a Script Manager called "General Robot Management" but I didn't want to throw that complication in here.
A typical sequence would go like this:
Speech Phrase ="Cancel game"
There are only 2 lines in the Speech Recognition script for Cancel game:
In the RPS Main script there may be many things starting things off but the salient points are:
$SpeechPhrase is a system generated variable that holds the last phrase spoken by the user. It is used to select the correct response via IF-ElseIF statements.
I list the phrase responses alphabetically (according to their first letter), in groups for faster responses. Listing them alphabetically like that allows the IF-ElseIF statements to skip entire blocks of scripts at a time. Like this:
Doing so would also make them easier to go through manually since they would be alphabetically ordered. Assuming you entered the scripts under the main alpha areas alphabetically as well. The second and third letter is also used in a similar fashion to further skip groups of scripts, making this method even faster. I further speed up the search by actually using goto statements, like this:
I am not showing the use of the second and third character from the phrase to further divide up the searching so as to keep things reasonably simple (yeah, I know, too late )
The main point I am making is that moving all the phrase response scripts to one external script can greatly facilitate script modifications and searches later. It can also aid in doing repetitive things in a central script rather than over and over in many scripts.
Thank you and you're welcome. The overall concept is broader and more complicated than I posted here. I just wanted to cover the concepts and provide some relatively simple examples. If you would like to know more about the real nuts and bolts let me know and I can post a project to the cloud that you could download and have a look. I could include a notepad with a description of what is going on. Although more complicated in some ways, it's also more compact in others. For example, I've adopted a shorter, more abbreviated script naming system. What I showed in the examples was wordy so as to convey the ideas through the names themselves.
Sounds like a very good way to organize scripts and the responses or commands.
Tying up loose threads today and wanted to let you know I am not ignoring you. I've been making some modifications to my methods that involves being able to remove ALL scripts from the script areas in the Speech Recognition window. This allows them to be ordered alphabetically and searchable. A must when you get to the point of having dozens, or even hundreds of phrases to deal with. If you use script managers to hold related scripts in an overall "program," you can even have a separate speech response evaluation script in each of them, further modularizing your code.
Anyway, I'll be posting an Example Project in the next few days. It will include a notepad containing explanations of it all, as well as, copious code comments in the scripts.
I have uploaded a basic demo project of the method I used to move the scripts from the Speech Recognition control to an external script. I was writing up my whole project concerning this, which also addressed issues with using the scripting language for this sort of thing, as well as, ways to navigate around them. This more elaborate scheme was needed because I was also making it work such that the scripts from the Speech Recognition control could be distributed to several external scripts instead of just one. This allowed the speech evaluation scripts to be placed in a Script Manager along with other scripts pertaining to a specific overall operation. But I decided that for now, I would just present this aspect of the methods used.
There is a notepad in the project detailing the purpose of the scripts included and the concepts used. Let me know if you have any questions.
The project is titled ESRP (External Speech Recognition Processing).
I also have a method of assisting in the search of the entries in the Speech Recognition control. Right now the Speech Recognition control contains no methods for searching it. Even with the removal of the scripts to a searchable external script, there is still no way to search the phrases still in the Speech Recognition control. You can, however, add a few lines of code to each script to make it announce the row a given phrase is on by simply speaking the phrase.
What you would do is place the following in each script:
Putting the number of the row in the first line of the script will result in that showing up in the script box right up front, giving you a line number to view as well. That will make it easier to get to the row number desired as you scroll through the rows. Also putting several spaces right behind the number in the first row will make it stand out better by pushing the next line back.
In this way, setting the variable $SRMode to the value of the variable $Search the Speech Recognition control will speak it's row number when you say the phrase associated with it.
Those variables would be declared wherever is convenient for you like this:
Then you simply set $SRMode to $Search when you want the Speech Recognition to say a location when you say the phrase, Setting it back to $DoNotSearch will keep it from doing that.
You can, alternatively, set $SRMode directly to "0" and "1" or True and False. It's not mandatory to declare $DoNotSearch and $Search. They just make the code more readable. At the very least, however, $SRMode has to be declared somewhere before it can be used.
Of course, if you are removing all the phrases to an external script then you simply put this script into each script area for each phrase.
What will happen then is that the script in the external evaluation script will run first, then it will say it's row number. To prevent the script in the external evaluation script running you would have to put in an IF condition looking for the $SRMode variable to be $DoNotSearch to allow it to run. This could be placed at the beginning of the whole script so as to prevent anything from running until the $SRMode variable is set back to $DoNotSearch.
Naturally you have to change the number to reflect the row each is actually in.