Strange behaviour "stop VA listening"

[Troublemaker]

After "Stop VoiceAttack listening" it doesn't react to any of my commands - as expected...
But after 20 seconds I activate listening again and then all the commands given while it was not listening, are being processed one after the other... 

Video of the behaviour:
https://youtu.be/t_3mui6rq10

Relevant piece of code:

Code: [Select]

Say, 'Ok captain.' or ' Roger.' or ' Sure captain.'  (and wait until it completes)
Stop VoiceAttack listening
Pause 10 seconds
Press down Left Shift key
Pause 0,421 seconds
Press E key and hold for 0,073 seconds and release
Pause 0,11 seconds
Release Left Shift key
Pause 0,367 seconds
Press 1 key and hold for 0,078 seconds and release
Set Boolean [exit1State] to True
Pause 10 seconds
Start VoiceAttack listening


[Gary]

If you are not running third-party apps that may be interfering (like TeamViewer, Synergy, etc), you may want to try what is indicated in this thread:

http://voiceattack.com/SMF/index.php?topic=64.0

That seems to help a lot.

[Troublemaker]

Thanks, but I'm pretty sure that's not the root of the problem.

I created a new speech profile just a few days ago. Since then I spent quite a lot time to train it for my ATC addon, I'm using in FSX. It works like a charm and I would not like to delete it just to find out, that wasn't it... 

Another detail:
If I switch to "not listen" by hand - by clicking the icon - it works. But not if I do it from a command. This fact tells me, that there's something wrong with VA, not the speech recognition itself... 

Oh... BTW: VA was running alone. No third party apps, beside some joystick profilers, avast and my spam-filter...

[Gary]

VA is not stopping the events from triggering.  Once a speech event triggers, VA does what it's supposed to do.  I recall seeing this issue before, but I'm having a hard time remembering the solution.  I was thinking it was the speech profile.

[Pfeil]

I can confirm, commands spoken while VoiceAttack is set not to listen via command are executed when it starts listening again in some cases.

This simple command has the same issue:

Code: [Select]

Stop VoiceAttack listening
Pause 10 seconds
Start VoiceAttack listening

I've spend over an hour(closer to two probably) testing various scenarios, and I can reproduce the following:

If a command with "Stop VoiceAttack listening" pauses a number of seconds, then executes "Start VoiceAttack listening", anything spoken during said pause will execute as soon as listening is enabled.
This also occurs when using "Execute Another Command" to start listening using a different command, even with "Wait until this command completes before continuing" is not checked.

To clarify:

• "Stop VoiceAttack listening" is executed
• Listening suspended
• "<Pause for 30 seconds>"
• Speak commands, phrases, or anything picked up by the speech engine
• Wait 20 seconds or more for the pause to run out
• "Start VoiceAttack listening"
• "Listening Resumed"
• Commands execute, or "Unrecognized :" added to log

If "Start VoiceAttack listening" is removed from the command, and the UI "Listening" button is operated while the pause is running, the following can be observed:

• "Stop VoiceAttack listening" is executed
• Listening suspended
• "<Pause for 30 seconds>"
• Speak commands, phrases, or anything picked up by the speech engine
• "Listening" UI button clicked
• "Listening Resumed"
• Wait 20 seconds or more for the pause to run out
• Commands execute, or "Unrecognized :" added to log

I also tested using TTS with "Wait until speech completes before continuing command" checked, and a keypress which held down for 10 seconds, instead of a pause, both of which gave the same result; Though that may be down to those using the same underlying function as "Pause".

If listening is resumed manually by clicking the UI "Listening" button right after the pause runs out(Well, as soon as the command wrote to the event log to let me know it was, and some added delay for reaction time), nothing appears in the log, and no commands are executed.


As requested, I created a new speech profile and tried again, the behavior did not change. I rebooted, created another one before opening VoiceAttack, and tried again: The behavior did not change.

EDIT: Another quirk to add: If "Allow other commands to be executed while this one is running" is checked on the stop-pause-start listening command, nothing appears in the log, and no commands are executed, if spoken during the pause.

[Gary]

Strange that you should mention it, yesterday I found some extremely old code that may be causing this.  The code was removed last night but has not been released.  I'll see if I can reproduce your scenario with the updated code.

[Gary]

What was in place is if a command is issued while VA is 'not listening' that contains a, 'start listening', the code would allow that command to start the listening up and allow the command to execute.  Back in the early days, I didn't want to make a global, 'start listening' command or commands.  I wanted to be able to offer it as an action as well.  I'm almost inclined to think this was even before there were multiple actions per command (macros).  Then, when there were multiple actions per command, what to do with, 'start listening' if somebody calls it and also wants to play some kind of TTS with it (or a sound or whatever).  Well, the only real solution was to just turn listening on if, 'start listening' existed in the command and let it go.  This was before subcommands and conditional statements and all that stuff.  What I just realized is that removing this code also removes the ability to issue a simple command to just turn on listening (which is handy, and I would really miss that).  So, what to do?  What I'm thinking is that if the action to turn on listening is the FIRST action in the command (or possibly the only action in the command) to allow it to do what it's been doing all this time (turn on listening, run the command).  Otherwise, it just trucks on past as if it's not listening.  The alternative is to provide a global or profile-level list of keywords to turn on listening.  You'll also find this weirdness in the, 'ignore command' command.  It's all so it's not in a great big profile-level list.

[Pfeil]

What I'm thinking is that if the action to turn on listening is the FIRST action in the command (or possibly the only action in the command) to allow it to do what it's been doing all this time (turn on listening, run the command).  Otherwise, it just trucks on past as if it's not listening.  The alternative is to provide a global or profile-level list of keywords to turn on listening.  You'll also find this weirdness in the, 'ignore command' command.  It's all so it's not in a great big profile-level list.

From the fact that commands with "Start listening" work, I'll assume that the speech engine itself is always active, and VoiceAttack simply discards any input(currently with the exception of commands containing a "Start listening" action). Therefore, the main question is how you want to present this feature to the user.

Another alternative would be a checkbox in the "Edit a Command" window, I.E. "Execute this command even when listening is suspended".
This would allow the user to execute certain commands without needing to enable listening for all commands(assuming this would be a useful feature).

EDIT: Thinking about it, the same could be achieved by starting a command with "Start VoiceAttack listening" immediately followed by "Stop VoiceAttack listening".

I don't feel a list of commands in the profile options is the best way of going about it. If the concern is knowing which commands will execute when listening is disabled, perhaps a filter for the command list would work instead(Similar to "disabled attribute" filters currently implemented).

[Gary]

Thanks for all your help (here and everywhere).

The thing about it is it's been fine all these years and is just now starting to become a problem.  I may just stipulate that it can still work the way it was if and only if a start listening action is the first action in the command.  I would like to be bold and say that most folks that use that action to turn on listening probably only HAVE one action in their commands.  Anybody that's using it for more complicated stuff would have it all wrapped up in conditions or whatever. 

You are correct about the speech engine being on all the time... the requirement in the beginning was to be able to kick things back on with a voice command.  It's kind of hokey the way it is, but, all it's really for in this context is to turn listening on when listening is not on and then the software started doing lots more stuff (and now its a bag of cats...  or 15lbs of crap in a 10lb bag lol)  o_O

[Pfeil]

Thanks for all your help (here and everywhere).

I would like to be bold and say that most folks that use that action to turn on listening probably only HAVE one action in their commands.

Most likely. Some may have TTS or a sound play to tell them listening is resumed, but I'd think it logical to place that action after "Start VoiceAttack listening".

the software started doing lots more stuff (and now its a bag of cats...  or 15lbs of crap in a 10lb bag lol)  o_O

[TheGrayFox]

Most likely. Some may have TTS or a sound play to tell them listening is resumed, but I'd think it logical to place that action after "Start VoiceAttack listening".

That's how I use it.  "Computer" is the word I use to override "not listening".

When I say, "Computer Standby"

Code: [Select]

Begin Boolean Compare : [ComputerStandby] Equals True
    Say, 'Confirmed.'
End Condition - Exit when condition met
Set Boolean [ComputerStandby] to True (save value to profile)
Say, 'Standing by.'
Stop VoiceAttack listening
Disable Hotkeys
When I say, "Computer Resume"

Code: [Select]

Begin Boolean Compare : [ComputerStandby] Equals False
    Say, 'Already on duty, sir.'
End Condition - Exit when condition met
Start VoiceAttack listening
Enable Hotkeys
Set Boolean [ComputerStandby] to False (save value to profile)
Say, 'Awaiting orders.'

[Pfeil]

Before, if a, 'Start Listening' action was discovered
        *anywhere* within a command and listening was off,
        the command would execute as if VoiceAttack was listening.
        This was for convenience and was left over from the
        early days when there wasn't much going on.
        The design has changed slightly.  This behavior is still
        available, however, it is only available if the FIRST
        action in the command is a, 'Start Listening' action.

Tested with v1.5.8.21: Spoken commands and phrases will be executed/added to the log as unrecognized when spoken during the pause, even though "Start VoiceAttack listening" is not the first action in the command:

Code: [Select]

Stop VoiceAttack listening
Pause 10 seconds
Start VoiceAttack listening

To clarify:

• "Stop VoiceAttack listening" is executed
• Listening suspended
• "<Pause for 30 seconds>"
• Speak commands, phrases, or anything picked up by the speech engine
• Wait 20 seconds or more for the pause to run out
• "Start VoiceAttack listening"
• "Listening Resumed"
• Commands execute, or "Unrecognized :" added to log

If "Start VoiceAttack listening" is removed from the command, and the UI "Listening" button is operated while the pause is running, the following can be observed:

• "Stop VoiceAttack listening" is executed
• Listening suspended
• "<Pause for 30 seconds>"
• Speak commands, phrases, or anything picked up by the speech engine
• "Listening" UI button clicked
• "Listening Resumed"
• Wait 20 seconds or more for the pause to run out
• Commands execute, or "Unrecognized :" added to log

The commands/phrases don't contain "Start VoiceAttack listening", so I guess it's logical they're not affected by the fix in .21?

EDIT: Though, even this command:

Code: [Select]

Say, 'ergerg'
Set Windows clipboard to 'dfbdfb'
Begin Boolean Compare : [fb] Equals False
End Condition
Start VoiceAttack listening
Still triggers when listening is disabled. It doesn't appear anything has changed after all

[Gary]

I'll look it over again.  Thanks for the heads-up.

[Gary]

/facepalm

Yup... I went back and, 'tweaked' that section and bugged it out.  Looks like it will be working right in the next release.  Sorry about that.

[Gary]

I think this has been resolved.  The requirements to have VA start listening with a command will require that the start listening action be the FIRST in the list, as well as 'when I say' needs to be checked (of course).

[Pfeil]

Tested with v1.5.8.22, VoiceAttack will still execute commands if a command is paused while listening is suspended.

This time I did an additional test, by executing a command containing nothing but a pause, and manually suspending listening(with the UI button), speaking some phrases, waiting a few seconds, and manually resuming listening. After the pause had elapsed, the phrases appeared/commands were executed.


Having "Start VoiceAttack listening" as the first action in a command appears to work as intended, however, comments at the start of the action list will prevent it from working.

As comments don't appear in the "Actions" column of the command list, I would assume they do not "count" as actions, so is this intended behavior?

[Gary]

I left it so that if anything is in the first line other than the 'start listening' action it should just skip on by.

[Gary]

Tested with v1.5.8.22, VoiceAttack will still execute commands if a command is paused while listening is suspended.

This time I did an additional test, by executing a command containing nothing but a pause, and manually suspending listening(with the UI button), speaking some phrases, waiting a few seconds, and manually resuming listening. After the pause had elapsed, the phrases appeared/commands were executed.

Having a hard time reproducing this.  I have two commands in a profile:
One called, 'pause' that pauses for 10 seconds and the writes, 'done' to the log.
The other is called, 'desktop' and it presses WIN + D.

I call, 'pause' and it pauses.  I click on the, 'listening' icon to stop listening.
I call, 'desktop' three times and nothing happens. 
'Done' is written to the log. 
I click the listening icon again and nothing happens (other than turning on listening).

I call, 'pause' and it pauses.  I click on the, 'listening' icon to stop listening.
I call, 'desktop' three times and nothing happens. 
I click the listening icon again and nothing happens (other than turning on listening).
'Done' is written to the log. 



I tried all those steps again but with having the, 'allow other commands to run...' checked.
Nothing seems to be happening out of the ordinary.  Did I miss something?

[Pfeil]

I tried all those steps again but with having the, 'allow other commands to run...' checked.

If the command initiating the pause has "Allow other commands to be executed while this one is running", everything works as expected and nothing appears in the log/is executed.

It doesn't make a difference whether the commands that are executed have it checked though.


Manually, I'm stopping and starting listening within the pause, allowing 10 seconds or so before I resume listening(to make sure it's not the speech engine still interpreting when listening has already resumed), and another 10 seconds before the pause runs out.


EDIT: Started a brand new profile just in case, same issue. Attached, just in case.

EDIT#2: Added a reboot, 'cause Windows, but no change.

[Gary]

I think I'm seeing what is up.  I'm going to have to think this one, as it's got some threading stuff going on.
Thanks for helping me out with that.

[Gary]

I think this one has been wrangled in the latest beta:

http://www.voiceattack.com/beta

*Hoping*

[Pfeil]

Commands executing after a pause, if listening was disabled and re-enabled during said pause, has been resolved.

However, the messages to the user(which are otherwise quite nice), are somewhat unclear:

With "Cancel blocked commands" checked:

Done
Listening resumed
Command cancelled: Another command is not allowing others to execute.
Command cancelled: Another command is not allowing others to execute.
Listening suspended
<Pause for 30 seconds>
Recognized : 'pause test' (Confidence 93)

With "Cancel blocked commands" unchecked:

Done
Listening resumed
Command waiting: Another command is not allowing others to execute.
Command waiting: Another command is not allowing others to execute.
Listening suspended
<Pause for 30 seconds>
Recognized : 'pause test' (Confidence 95)

As you can see(in reverse order, yes I could've changed that setting  ), commands don't execute after the pause regardless of the setting, but the log message doesn't reflect that.

I would argue that any message in this case is unnecessary, as commands aren't supposed to execute with listening disabled, with exception of "Start VoiceAttack Listening" commands.


Speaking of "Start VoiceAttack Listening" commands, they will also wait until the end of the pause before executing, or not executing at all with the appropriate option. This does mean that it's important for users to check "Allow other commands to be executed while this one is running", if they anticipate a need to "break out" of suspended listening while a command is paused(whether said command suspends listening or not).

[Gary]

Ack... I see what I did there.  I moved some code up to an earlier point and it's giving a false message.

Good catch!

[Gary]

Ok, so, the problem was that when listening was off, the warning was being generated.  That seems to be fixed and also seems to work properly if listening override is used.

'Cancelled' is now, 'Canceled'.

Speaking of "Start VoiceAttack Listening" commands, they will also wait until the end of the pause before executing, or not executing at all with the appropriate option. This does mean that it's important for users to check "Allow other commands to be executed while this one is running", if they anticipate a need to "break out" of suspended listening while a command is paused(whether said command suspends listening or not).

"Start VoiceAttack Listening" actions in commands are still in commands.  They follow the same rules as other commands in that regard.

I'm under the belief that synchronous commands (commands without the, 'allow other commands to run' option checked) are relatively rare and should be used sparingly as well as only be used with fairly short commands. 
Then to throw listening not on and then use a voice command to enable listening (which is even rarer still) and have the user be surprised that there is no warning is seriously edge case and is kind of splitting hairs, don't you think?

[Pfeil]

I'm under the belief that synchronous commands (commands without the, 'allow other commands to run' option checked) are relatively rare and should be used sparingly as well as only be used with fairly short commands.

They're actually the most common type of command in my(and my case may be a minority) profiles. I tend to automate menu manipulations, which means long sequences of keypresses, mouse movements, and clicks, that shouldn't be interrupted.

I actually had typed up a feature request for a third type of command priority, "Always Execute this command regardless of running commands", but this would leave the interface in an unpredictable state with most types of output, so the utility of such a feature is limited.
I still would've liked to use it for controlling my media player(through a plugin, so no keypresses and such), but that's hardly worth the effort of implementation.

Then to throw listening not on and then use a voice command to enable listening (which is even rarer still) and have the user be surprised that there is no warning is seriously edge case and is kind of splitting hairs, don't you think?

Yeah, pretty much.