Token support for "Wait For Spoken Response"

[Pfeil]

To my surprise I found out "Wait For Spoken Phrase" does not accept tokens, which severely limits its utility in more advanced commands.

Would it be feasible to implement this?

[Exergist]

Seconded for increased flexibility

[Gary]

I think this should go in as well.  It will require a profile reset, just like the commands require it.  Is that something that would be OK?

[Exergist]

[Gary]

I put a seriously unofficial build out in, 'unofficial', just to get that ball rolling:  http://www.voiceattack.com/unofficial

I changed the code in the two places that I thought it should go.  You will have to reload the project for those to show up, as the responses are loaded when the profile loads (which means that, 'not set' will be a response for every token that relies on variables when the profile is first loaded).  I'm also thinking that only global variables and profile variables where the values are maintained (using the >> prefix) will work.  Could be wrong... haven't tested any of this out much.  It will still be another (probably) two weeks before I can get real time back on this   I just happened to get a few minutes in tonight & thought I'd share what I have so far.  On the other hand, there's a good possibility that's all the work that was needed to be done (also, there is no tooltips or docs yet)    Good luck

[Pfeil]

It's possible to set an initial value without having to reload the profile using something like

Code: [Select]

{EXP: IIF('{TXT:test}' = 'Not Set', 'Default value', '{TXT:test}')}
For which a shorthand token working like the null-coalescing operator could be useful, like

Code: [Select]

{EXP: '{TXT:test}' ?? 'Default value}'or even

Code: [Select]

{??:{TXT:test}:Default value}

However, it seems that may not actually be necessary?!

This:

Code: [Select]

Set Text [test] to '{TXTRANDOM:this is a test;testing one two;testing once more}'
Write [Blue] '{EXP: IIF('{TXT:test}' = 'Not Set', 'Default value', '{TXT:test}')}' to log
Wait for spoken response: '{EXP: IIF('{TXT:test}' = 'Not Set', 'Default value', '{TXT:test}')}'
Write [Pink] '{TXT:~response}' to log
"just works" in v1.7.2.23, in that whichever response is randomly picked will be recognized by the "Wait for spoken response" action, without having to reload the profile at all.
This also works fine even with command-scoped variables(tested with "~" prefix).

I tested with the "knock knock" example in this topic, which also works.

[Gary]

Thank you for all the info and testing.  I must clarify what I meant by work...  I meant work reliably, as the responses may only be as good as dictation (since the responses would not have been added as phrases to the dictionary on startup).  Hope that makes sense o_O.

[Pfeil]

Aha, that explains the somewhat spotty accuracy in the "knock knock" command; I figured it was just because the phrases were so short.

That does make it difficult to test, as recognition accuracy is subjective.


As I have no insight in the inner workings, this may be a ridiculous question, but would it be possible to replace the dictionary without reloading the entire profile, if only the phrases for this action can change?

Simplistically, if the phrase list for the profile's commands is retained after sending it to the speech engine, would it be possible to add the action's phrases to the end of it?

Hopefully would mean commands, even ones with tokens in the name(as they aren't reprocessed either), would still be addressable by their command phrase, so they are unaffected even while running, instead only the speech engine goes offline momentarily.


As multiple "Wait For Spoken Phrase" actions can run simultaneously, I can see that bringing additional difficulty.



I'm just thinking out loud, really.
My "objection" to reloading the profile is that it necessitates killing the calling command and wiping local variables, making it difficult to use in a stateful system, and without a handler in the profile's startup command to resume the process, nothing would happen afterwards without user intervention either.


Obviously I'm not demanding anything here, even though saying "To my surprise I found out" gives the wrong impression(I genuinely had a "huh, I thought it'd do that" moment, which is why I phrased it that way, forgetting the technical restrictions of the speech recognition engine, which is a compliment, really, as VoiceAttack manages to obfuscate that quite well ).

[Gary]

I've got some more stuff in the works for this (speech engine gets updated on-the-fly and not requiring the profile to be reloaded).  A little more testing and it should be ready for trying out.  It's probably safe to go to beta, as I've made tokenized responses kind of separate from the original code (that is, tokenized (variable) responses are handled slightly different than the static responses).  The only limit right now (other than the 250 items per response) is that the maximum number of simultaneous, tokenized spoken responses is limited to eight (before the speech engine is purged)... which may be overkill as I'm not sure how useful/effective more than one or two 'Wait for spoken response' actions running at the same time will be.

Edit - New beta out there!

[Pfeil]

In a single instance, this seems to be performing well!

Words that are completely unrecognized otherwise(as they're not in the dictionary) work fine even when set through a token


However, when running multiple commands simultaneously, one appears to be affecting the other.

When two commands run this action simultaneously, the first-started instance will complete the second, even though "Continue on any Speech" is unchecked.

Even stranger, if they both use the same command-scoped("~")"Text Variable", the result of the first instance will be written to the second instance as well.


I'm testing using

Code: [Select]

Set Text [~test1] to '{TXTRANDOM:OmniWrench;Walloper;Sheepinator;Synthenoid}'
Write [Purple] '{TXT:~test1}' to log
Wait for spoken response: '{TXT:~test1}'
Write [Black] '{TXT:~test}' to log
and

Code: [Select]

Set Text [~test2] to '{TXTRANDOM:OmniWrench;Walloper;Sheepinator;Synthenoid}'
Write [Pink] '{TXT:~test2}' to log
Wait for spoken response: '{TXT:~test2}'
Write [Gray] '{TXT:~test}' to log

If the commands use a different "Text Variable", the second instance will return "Not Set" instead.

Both actions have their "Timeout" value set to 0 for none.

Commands are attached.

The only limit right now (other than the 250 items per response) is that the maximum number of simultaneous, tokenized spoken responses is limited to eight (before the speech engine is purged)... which may be overkill as I'm not sure how useful/effective more than one or two 'Wait for spoken response' actions running at the same time will be.

Just so we're clear: The limit of 8 is on "Wait For Spoken Response" actions running simultaneously(in different command instances, by definition), not response phrase variations using tokens?

E.G. you can have 8 "Wait For Spoken Response" actions running at the same time, each having up to 250 phrases which could be generated by 250 tokens.

[Gary]

You can have as many wait for response actions running simultaneously, with both tokenized and standard phrases.  However, only 8 of those can be tokenized.  If you somehow have nine running, the first one will be queued out.  It was an optimization decision (versus rendering ALL tokenized responses on every, 'wait for response' action).

[Gary]

I put a build out in, 'unofficial' if you would like to try it.  This *may* fix the issue you are describing.  I have to get away from my desk for the night, so, I thought I'd throw what I've got out there o_O

Thanks for the heads up!

http://www.voiceattack.com/unofficial

[Pfeil]

Seems to work well; Multiple instances remain independent, and can be triggered in any order(in v1.7.2.24, only the first instance actually worked, something I intended to mention but apparently didn't).

[Gary]

only the first instance actually worked

That manifested itself rather quickly  

Thanks for the update, Pfeil!