Side note: Great tool. It was easy to install and worked the first time.
Thanks! Always nice to hear. Hmm, this is more something that I’ve thought of as being solvable via UI (for instance, however you signal the user that you are listening, don’t signal that when the app is talking) but I can definitely see the advantage to being able to stop playback programmatically.
This would really not be hard for you to hack in quickly, because you are only trying to call FliteController’s method interruptTalking directly. You’d just need to check whether FliteController exists and if so, call interruptTalking.
If you wanted to bring the complete OpenEars architecture to bear on it so everything is nicely decoupled and standard, you could create a new OpenEarsEventsObserver delegate method (fliteSpeechRequestedToInterruptTalking might be a self-describing name) and look at the various examples of how notifications are sent to OpenEarsEventsObserver throughout the framework to see how to signal it when you want to request that playing speech is interrupted (presumably this would happen as a result of a new method for PocketsphinxController which could be named something like “interruptTalking”). Then you can add the new delegate callback to FliteController since it already inherits OpenEarsEventsObserver and when it is called, call interruptTalking. If/when I add this feature it will look something like that. The advantage is that the parts of the framework can remain ignorant of each other’s status.