Author Topic: Token support for "Wait For Spoken Response"  (Read 121 times)

Pfeil

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1544
  • RTFM
Token support for "Wait For Spoken Response"
« on: September 09, 2018, 04:01:34 pm »
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

  • Sr. Member
  • ****
  • Posts: 331
  • Can you dig it?
Re: Token support for "Wait For Spoken Response"
« Reply #1 on: September 17, 2018, 02:03:47 pm »
Seconded for increased flexibility

Gary

  • Administrator
  • Hero Member
  • *****
  • Posts: 1705
Re: Token support for "Wait For Spoken Response"
« Reply #2 on: September 17, 2018, 06:11:37 pm »
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

  • Sr. Member
  • ****
  • Posts: 331
  • Can you dig it?
Re: Token support for "Wait For Spoken Response"
« Reply #3 on: September 18, 2018, 07:14:44 am »

Gary

  • Administrator
  • Hero Member
  • *****
  • Posts: 1705
Re: Token support for "Wait For Spoken Response"
« Reply #4 on: September 18, 2018, 08:51:55 pm »
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1544
  • RTFM
Re: Token support for "Wait For Spoken Response"
« Reply #5 on: September 19, 2018, 05:28:02 am »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 1705
Re: Token support for "Wait For Spoken Response"
« Reply #6 on: September 19, 2018, 05:52:50 pm »
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1544
  • RTFM
Re: Token support for "Wait For Spoken Response"
« Reply #7 on: September 21, 2018, 02:56:17 am »
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 :) ).