Creating dynamic voice commands the easy way?

[gkzone]

I was struggling trying to use the {CMDSEGMENT:} token to dynamically create a variable to use later in the command. The way you have to tokenize the segments can be difficult when using numbers or time as a dynamic variable. Additionally, too many tokens (options) could affect the performance if you're working with large numbers as an input, for example.

Then I ran across the {LASTSPOKEN} token in the documentation. This token "renders the text captured by the speech engine regardless of whether or not the command was recognized."

Here is how I'm doing it:

• Play sound (notifying that the command was recognized and the user can speak the next input
• Wait for spoken response (set to continue on any speech)
• Set text [variable] to {LASTSPOKEN}
• The rest of the command.

I've found this method to be far more reliable than trying use {CMDSEGMENT:}, particularly when working with numbers or time.

[SemlerPDX]

That's a nice workaround, and you can provide a prompt to signal that the user should then speak the value.

You can use a command segment by targeting the number of that segment quite easily, too.

In your top example, you may have instead: "Set background music volume to [0..100]"

...in this manner, the portion of this 'When I say' phrase "Set background music volume to" is {CMDSEGMENT:0} and the numbers which can be spoken (from zero to 100) would be {CMDSEGMENT:1}. There would be nothing unreliable in this format, and in general there is nothing unreliable about the {CMDSEGMENT} token.

You could even account for both forms of entry, such as how you have it now, and also if the value was spoken:

'When I say':  "Set background music volume;Set background music volume to [0..100]"

...

In this way, you can first check if {CMDSEGMENT:1} has value or if it is empty/Not set - if it has value, you could set your volume value variable to this value directly, else use your existing 'Get Response' method, for added versatility.

 

[SemlerPDX]

Wanted to say that you can also directly get the numbers (or input) you want to get from users in a "Wait for spoken response" action like this:

[gkzone]

Yes, I didn't really have an issue getting a smaller value, like 1..100. However, the inefficiency of CMDSEGMENT is that a range of 1..100, you are in effect creating 100 additional commands.

The main reason I came up with this idea was for the prompt to get the time. The "wait for spoken response" command requires that you create an array of possible responses. I couldn't figure out a way to prompt for time. It was always "not set." I even tried breaking it out by hour, minute, meridian, but had inconsistent results. For example, it didn't like [1..12], it did however take [one;two;three;...].

With the method I'm using the variable can be any value, not just an array of possible values. The name variable for the "name" of the alarm can be any word(s) I can speak in the time I'm allowing in the prompt. LASTSPOKEN returns the value as text, however, so converting the type may be necessary as it was with time.

[SemlerPDX]

Yes, I didn't really have an issue getting a smaller value, like 1..100. However, the inefficiency of CMDSEGMENT is that a range of 1..100, you are in effect creating 100 additional commands.

Oh, I get what you mean now. It is a good idea to try to keep down the total number of commands and derived commands in a profile, as this can help keep profile loading time to a minimum. It won't affect the speed or ability to listen for all those commands once a profile is loaded, but the more commands you have, the longer it can take to load a profile or apply changes to editing the profile. That being said, a hundred commands is nothing really, in and of itself, it's when you get up to the hundred thousand range that it could take 5 seconds or more to load a profile.

My daily use profile has 300 commands, but over 100,000 derived commands, and still loads relatively fast....