Enqueue Commands by Voice

[Careless]

HI,

At this point I've made some complicated Profiles for different games, and my main Desktop profile. However, I would like to know if there is a way to chain certain existing commands together to execute back to back by using some sort of in between enqueue action. I tried making my own using wild card, but it didn't work as expected(see attached). I'm hoping that something like this can be achieved.

Ex. I play Star Citizen, and I have two commands called 'Start the ship' and 'Contact ATC'. What I would like to happen is that those both execute back to back by saying something like 'Start the ship, and then, Contact ATC, and then....'. If possible I would like the queue to be as long as the commands I keep giving it, but not to all execute at the same time, but rather when the previous command finishes it moves on to the next.

Thanks for any help!

[Pfeil]

Command phrases must be either fully predefined, or use wildcards which utilize the dictation capabilities of the speech recognition engine.

If you want to speak two arbitrary phrases connected by a third phrase, you need "*" characters on both sides of that third phrase (I.E. before and after).


As wildcards do require the speech recognition engine to freely recognize what you're speaking, without context, recognition accuracy will likely be less than when matching to predefined phrases.

If you anticipate wanting to combine specific commands, creating a command that has those combined phrases predefined would be the most reliable approach.

[Careless]

A little bit of outside of the box thinking, but let me know if this is maybe something that's possible.

Let's say I make a command called "New Command Queue," and that'll start dictation where I would then dictate the commands I would want to be queued. Can I parse the dictation for recognizable commands that I could then populate in a queue using a loop?

And the main reason I would want this is so that the queue would be dynamic. I do suspect a few commands to be called right around the same time, but some of the ones I would want in the queue would be dynamic such as a prefix/suffix group.

[Pfeil]

Depends on what you mean by "parse the dictation for recognizable commands". You'd need to have your own list of commands to check against, as there is no method for getting a list of available commands from loaded profiles, unless you intend to rely on perfect dictation accuracy (as well as never making a mistake while speaking).

If you have a list, then yes; as you are already aware, commands can be queued by name (phrase).


That said, if you're going to predefine a list of commands anyway, you could use the "Wait For Spoken Response" action rather than freeform dictation. The recognition accuracy of the former should be equivalent to regular predefined commands.

[Careless]

This is what I came up with, and the dictation passes and takes fine but only when I specifically say something that isn't already a preprogrammed command. Whenever I say something that is a preprogrammed command the dictation returns as an empty string. Any thoughts? Also, for some reason it isn't taking my 'No' response for the while loop to exit, instead it just times out if it never hears yes. Thanks for all your input, I imagine this venture will be unsuccessful but I figured it was worth a try.

[Pfeil]

If you are speaking just a predefined command phrase while dictation mode is active, the command should be executed instead of the recognized text being added to the dictation buffer.

As such, the output of the "{DICTATION}" token should be blank, as the buffer is cleared when dictation mode is started, and not appended.

To be able to speak command phrases in dictation mode, you'll need to prefix them with something, E.G. "enqueue".
The "{TXTSUBSTR:}" token can be used to remove this prefix.


Have you checked whether "no" is actually being recognized? The "Wait For Spoken Response" action does not provide any feedback through the log on the main window.
You can check the output by inserting a "Write a Value to the Event Log" action after it that writes the output of "{TXT:addYesOrNo}" to the log.

I will point out that "Yes; No;" would normally create a blank section, which is not valid input. Though this likely won't prevent the action from functioning, as it should be removed internally.