decimal recognition in number range command

[jaus]

I have a command:

     lower flaps [1..5] seconds

it works if I speak integer values of 1-5, but I want to be able to say '1.5 seconds' or other decimal values.    If I do this  the speech interpreter gets it right, but the command is not recognized.   

How do I get VA to recognize a decimal value in this scenario.   Ultimately I want to create a decimal value with {TXTNUM:variable} that I can use in a variable pause between a key press and a key release.

[Pfeil]

Numeric ranges do not accept non-integer numbers, however the "{TXTNUM:}" token should interpret two of them separated by a period as a single number.

E.G. without modifying the actions within your command, your command phrase could be something like lower flaps [1..5] seconds;lower flaps [0..4].[1..9] seconds
so you can speak "lower flaps one point five seconds", and have it be recognized and parsed as 1.5

[jaus]

Looks interesting, thanks.

Can the first and last digits ( and the '.' in between) be made optional like this:

     lower flaps [1..5;] [.;] [1..9;] [second;seconds]

So that spoken commands like these would work:

"lower flaps 1 second"
"lower flaps .5 seconds"

[Pfeil]

While that would work, it would also generate unnecessary commands like "lower flaps 1 1 second" and "lower flaps seconds"

To add the ability to speak "lower flaps point five seconds", a more efficient way would be lower flaps [1..5] seconds;lower flaps [1..4;].[1..9] seconds


To get a list of what phrases will be generated, so you can tweak your dynamic sections, you could use this command.

[jaus]

I tried the command you described above.   When saying something like '1.6  seconds'  The interpreter captures the phrase correctly, but added a space on either side of the '.' (e.g. '1 . 6' ).   The set decimal function converts this successfully.

This worked in capturing the correct value for values with a number before and after the dash, but for a spoken '.2' , for example, the  interpreter captures it as '. 2'   which gets converted to a value of 2, rather than .2, by the set decimal function with {TXTNUM:variable}.

Can this be fixed, or worked around?

[Pfeil]

Makes sense, as the '.' character is then not part of a number, but merely adjacent to one.

You could include conditions that checks whether the '.' character is included in the command phrase, and whether it's also included in the output of "{TXTNUM:}", so that if the former is true, but the latter is not, you can prepend "0." to the output before passing it to the "Set a Decimal Value" action.

[jaus]

I think I have it working with this (image).

Thanks

[Pfeil]

That's certainly one way to do it.

Another option would be something like this:

Code: [Select]

Begin Condition : [{CMD}] Does Not Contain '.' OR ([{CMD}] Contains '.' AND [{TXTNUM:"{CMD}"}] Contains '.')
    Set decimal [~pauseTime] value to the converted value of {TXTNUM:"{CMD}"}
Else
    Set decimal [~pauseTime] value to the converted value of .{TXTNUM:"{CMD}"}
End Condition
Press down Left Shift+F keys
Pause a variable number of seconds [~pauseTime]
Release Left Shift+F keys


[jaus]

Interesting.... is this pseudo-code?   Or can you actually write code like this (with logicals) into VA?

I guess I'm still confused about the use of straight-brackets and curly-brackets.   Why are both needed around the CMD command in line 1  ... e.g.  [{CMD}]   ?

[Pfeil]

That is a direct copy of what you would see in the action list. You can use the compound condition builder to create more complex statements like that.

You can also edit existing single conditions with the condition builder by right-clicking them in the action list, and choosing "Edit With Condition Builder".


The square brackets are visual markup added for the action list, they are not part of the action's input in this case. E.G. the first section is a text comparison where "{CMD}" is placed into the "Variable Name / Token" field
Square brackets in the action list usually denote input in a field that takes variable names, whereas single quotes denote input in a field that takes literal text (and usually tokens, which are the equivalent of literal text, after parsing).


Square brackets are not part of the token syntax, which uses curly braces to wrap each token.
They are, however, used for dynamic command sections, dynamic responses for text-to-speech, and special key indicators.