Add method to disable speech plugin from python

[ShawnBuckley]

Adds the ability to shut down speech recognition plugin via python.

The problem I ran into was when adding a push to talk voice recognition was that while the push to talk button was not held speech was being recognized and queued internally, and as soon as the push to talk button was pressed all previously said phrases that should not have been recognized would fire.

This change would allow a user to configure speech recognition in a push to talk fashion like this:

if joystick[0].getDown(0):
  if speech.said("form on me"):
    # execute keyboard macro
else:
  speech.disable()

Rapidly enabling and disabling the speech recognition engine doesn't seem to have any performance impact.

[AndersMalmgren]

Hi, there must be a softer way of disabling speech recognition than disposing the whole thing?

[ShawnBuckley]

Sure. The goal I'd like to shoot for is to have speech.said not return true for statements that were said before speech.said was called. I'm going to look at other ways of accomplishing that. I think it would be nice to not have the recognition engine running while the user disabled/paused recognition but it is not the important feature.

[MarijnS95]

It seems the recognition engine is specifically programmed to look for specific words, ie. after speech.said() is initially called. Perhaps this API needs to be reworked to allow removing words/grammar from the recognition engine again with UnloadGrammar(Grammar) instead of disposing the whole thing, and stopping recognition if no active grammars are loaded through RecognizeAsyncStop().

This could either be through some speech.stop("form on me") or with an object representing the Grammar:

form_on_me = None
if joystick[0].getDown(0):
  if form_on_me is None:
    form_on_me = speech.recognize("form on me")
  elif form_on_me.said():
    # execute keyboard macro
    form_on_me.reset() # Or stop(). What if it's said again? You usually don't want the macro to be executed every time FreePIE iterates the script
else:
  form_on_me and form_on_me.stop()
  form_on_me = None

Could also have a .start() function and keep it initialized through speech.recognize just once.

[ShawnBuckley]

Another way of doing it could be have an active bool within the speech class that causes recognition by the recognitionEngine to be ignored. This would allow the user a minimal change to the python API, allow for using a push to talk style of recognition, and not dispose of the recognition enable to pause recognition.

It could look something like this:

speech.enable_recognition(joystick[0].getDown(0))
if speech.said("form on me"):
  # execute keyboard macro

[ShawnBuckley]

Made the change to support the example above. The plugin can still be fully stopped via the python interface but is not needed to pause the recognition engine from running to support to push to recognize.

[AndersMalmgren]

That seems much better!
I think we should remove stop. It makes no sense having the contrl to dispose the API from python.

More so since there is no corresponding start method. And no other plugin have exposed start/stop methods.

[MarijnS95]

Instead of Stop() should there perhaps be a Reset() method to get rid of all programmed grammars and mark all of recognizerResults as false (or empty the dict entirely)?

Currently it seems possible to call speech.said() once, the text is recognized but .said() is never called to check it again and set Result back to false, then after the user disables and re-enables the recognizer they will still receive true from speech.said() if called again. But perhaps that is intended.

In addition this enable function could use RecognizeAsyncStop() mentioned above to save some resources while FreePIE is ignoring results?

[AndersMalmgren]

Instead of Stop() should there perhaps be a Reset() method to get rid of all programmed grammars and mark all of recognizerResults as false (or empty the dict entirely)?

Currently it seems possible to call speech.said() once, the text is recognized but .said() is never called to check it again and set Result back to false, then after the user disables and re-enables the recognizer they will still receive true from speech.said() if called again. But perhaps that is intended.

In addition this enable function could use RecognizeAsyncStop() mentioned above to save some resources while FreePIE is ignoring results?

It was made so it would be as simple as possible for a non programmer.

[AndersMalmgren]

Maybe we should in DoBeforeNextExecute take all results and cache them until next DoBeforeNextExecute. And clear the dictionary. This way you only get one "frame" worth of results

[AndersMalmgren]

That might be a better solution becasue then you dont even need the enable feature

[AndersMalmgren]

That might be a better solution becasue then you dont even need the enable feature

[MarijnS95]

It was made so it would be as simple as possible for a non programmer.

For the record I wasn't commenting on the original design at all!

Just evaluating a bunch of scenarios and thinking up how we can make this as simple yet predictable as possible.

Maybe we should in DoBeforeNextExecute take all results and cache them until next DoBeforeNextExecute. And clear the dictionary. This way you only get one "frame" worth of results

Yeah, I think I like resetting it after a frame directly instead of resetting it only when speech.said was called. However, that may have severe implications when called in if blocks and might break existing scripts that rely on the current semantics.

[AndersMalmgren]

It was made so it would be as simple as possible for a non programmer.

For the record I wasn't commenting on the original design at all!

Just evaluating a bunch of scenarios and thinking up how we can make this as simple yet predictable as possible.

Maybe we should in DoBeforeNextExecute take all results and cache them until next DoBeforeNextExecute. And clear the dictionary. This way you only get one "frame" worth of results

Yeah, I think I like resetting it after a frame directly instead of resetting it only when speech.said was called. However, that may have severe implications when called in if blocks and might break existing scripts that rely on the current semantics.

Yep its for sure a breaking change. Might be worth it though

[ShawnBuckley]

Slimmed down the change to just include the speech.enableRecognition change

[ShawnBuckley]

@AndersMalmgren would there be anything else you'd like to see in this PR before it can be pulled?

[AndersMalmgren]

@AndersMalmgren would there be anything else you'd like to see in this PR before it can be pulled?

I want to do a POC on frame capture of speech input. I think it's a cleaner approach. The current state of the plugin is counter intuitive.