In another thread https://www.knowbrainer.com/forums/forum/messageview.cfm?catid=4&threadid=33424&highlight_key=y&keyword1=asleep

there is the advice

and, indeed, people say this all over the place now that I'm looking for it.

 

Q: has anyone written code to automatically turn Dragon "microphone off" if no speech has happened or greater than five minutes perhaps?

 

--

 

I have probably run into this a few times. I'm going to try to train myself not to say "go to sleep".

(Shoot, I said "goto sleep" as above, and it took 15 seconds to respond to "wake up".  That's annoying.)

 

I wonder if other ways of supposedly disabling speech have problems similar to sending the microphone to sleep:

 

(a) putting my headset on his charging stand (Sennheiser, per sig)

 

(b) muting using the button on the headset.

 

I would much rather use the mute button on the headset than have to say "microphone off", and, worse, click the DragonBar or use the hotkey to turn it back on.

 

 

 

 

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

I have used a hotkey to toggle the microphone on and off since the early days of speech recognition. I'm surprised DPG 15.5 does not include a default hotkey (Num+). I'm guessing Nuance removed the hotkey assignment because they noticed few people use it. Which is too bad. A hotkey is a very good way to toggle the microphone, but it only works if one is in the habit.

Turning the microphone on and off via hotkey is among the first Dragon skills I teach people.

With the exception of Forcing command recognition and Forcing dictation recognition, Nuance is no longer assigning preset hotkeys. We suspect that Nuance is no longer supporting the usual hotkeys to reduce technical support calls about hotkey conflicts. Future releases of Dragon will probably be handled the same way.

-------------------------

Forum Mission Statement
Trial Downloads
Dragon/Sales@KnowBrainer.com 
(615) 884-4558 ext 1

If you want to save a hotkey, the Push-to-Talk Dragon hotkey, if and when assigned, also turns off the mic when that button stops being pushed so you can press it like the Mic on/off button and know you are turning it off for sure (whereas the Mic on/off toggle button actually sometimes turns the mic on - e.g., when it is already off but you didn't know it) . . .

-------------------------

PG

Remember folks, my comments and this forum are for entertainment value only, please, no wagering or other reliance on the contents herein.  I permit no commercial use of my ideas (whether expressions or embodiments) without my written consent.

 

This is a generic problem with keys that toggle a setting or cycle through a set of values, as opposed to setting it absolutely to on, off, or an explicit value.

 

I did not quite understand what you said, though, about press to talk.

 

I do not want to have to hold a key down all the time that I'm talking. Isn't that what press the talk provides? Much of the time when I'm speaking I am not actually close to a keyboard.

 

I thought perhaps I could just make CapLock into the press to talk hotkey, but that does not seem to work. Although that might be because I have other hotkeys hooked to CapsLock via AHK; indeed, I have things hooked to double and triple clicking of CapsLock.  

 

--

 

One of the problems I have with the default Dragon NumKey+ for toggle microphone on/off is that on my keyboard NumKey+ is actually Fn+P - i.e. I need to type Fn to get a virtual number pad out of the QWERTY keys. I might try remapping it to something easier to type, but my standard go to easier to type key is spacebar.  Something like Ctrl+SpaceBar.

 

(I use compact keyboards, because the reduced size reduces reach required, helping hand pain for when I still have to type.  Also, laptops.)

 

If there were a key sequence that reliably turn the Dragon microphone off rather than toggle it I might bind it to something like Ctrl+SpaceBar.  

 

But I see that Dragon's HotKey system seems to disallow me binding to Ctrl+SpaceBar. (Or perhaps it is my existing bindings for SpaceBar getting in the way. Although I don't have anything bound to Ctrl+SpaceBar at the moment.

 

Perhaps this would be a good reason for one of those big buttons, like https://www.compuphase.com/usbkey/rfbutton_en.htm

 

But it would still be nice to set it absolutely as opposed to toggling

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

It's far from ideal if you must press the Fn key to access a frequently-accessed hotkey. I would go so far as to say that pressing and/or holding any kind of modifier key (Fn, Shift, Ctrl, Alt, or Win) is not the best option for Dragon hotkeys.

Compact keyboards usually have more keys accessed by pressing and holding "Fn" -- so you may need a creative solution.

If the Function keys are mapped to media keys on your computer (e.g., press F5 to increase speaker volume), consider which set of keys you need more: the media keys or the function keys. For me, function keys are much more valuable than media keys, so I permanently disabled them via the Bios. But pne of my clients wanted the media keys, so we had far fewer options for Dragon hotkeys.

In recent months I have mapped these 14 unmodified keys, via Dragon, to toggle the microphone. All seem to work:

All 12 function keys.
Insert key
Pause key

NumLock and ScrollLock can be assigned, but I'd be wary of using them. I would advise against using Home, End, Page Up, Page Down, and the four arrow keys, as there may be conflicts with built-in Dragon scripts that send these keys.

Since you are using AutoHotkey, review your scripts for key conflicts with Dragon. It might make sense to shut down AutoHotkey before assigning Dragon hotkeys, reenable AutoHotkey, and then test to discover the conflicts. Then change the AutoHotkey assignments.

For one client, we really did run out of keys, so I used an X-Keys (a programmable keypad). We were forced to use a weird key combination in Dragon that involved two modifier keys at once. With the X-Keys, my client only had to press a single key to activiate/deactivate the microphone instead of three.

PTT does what it says. You push it and mic is on so you can talk. You stop pushing, mic turns off. So pressing and releasing it will turn the mic off. You can still use all the other methods to turn a mic on and leave it on and dictate so it's not required to press a button. I use the default Dragon hotkeys but also map a mouse side button and Caps Lock key to trigger that hotkey which triggers the PTT. I also have a macro I can turn on and off that then maps the space bar as PTT too, but pressing and releasing space provides a normal space rather than quick pressing the PTT to turn off the mic (so the macro waits until the space is held for .4 sec before engaging PTT). Alternatively, I use to use the "quick tap release and hold" on the spacebar to engage PTT but found that holding for .4 sec worked better (though I sometimes miss my first word).

If you need a hot key to turn on the mic (not toggle), write a macro that pushes and releases PTT, unambiguously turning off mic first, then presses the mic on/off toggle hotkey and voila the mic is on. . .

-------------------------

PG

Remember folks, my comments and this forum are for entertainment value only, please, no wagering or other reliance on the contents herein.  I permit no commercial use of my ideas (whether expressions or embodiments) without my written consent.

Yeah, I have 2 X-key strips, one with four keys and one with 16 keys.   I was going down the path of lots of single key bindings (in AutoHotKey) to reduce typing before I remembered Dragon.

 

I'll probably do this, but nevertheless I'd still like to have a timeout. I suspect I will still forget to turn the microphone off, even if it is a single key.  Especially since I am often quite far away from my keyboard which is one of the joys of using Dragon.

 

By the way, I would thought that muting my microphone locally, on the headset, would be almost equivalent to microphone off from Dragon's point of view.  But a few experiments seem to show the following:

 

if I microphone off and have a phone conversation I can return to Dragon and resume pretty reliably,

 

If I send Dragon to sleep and do the same thing, I can much less reliably resume Dragon. This is as would be expected given the explanations you experts have provided.

 

Finally, if I use the mute button on the headset itself, Dragon has often misbehaved. It seems as if Dragon is doing something, if the microphone is on and Dragon is listening, even though the dictation source is locally disabled.

 

(I have noticed similar problems if I hang the headset up on its charging stand, neither muting nor turning Dragon's mike off. But I am less confident about those, because it's entirely possible that I haven't hung it on the stand properly, so it might still be listening.)

 

--

 

BTW: elsewhere I have asked about switching my headset between Dragon and a conferencing system like Zoom. When I tried this in the past I would tell Dragon to go to sleep while switching to Zoom... And now I understand why that would cause pretty bad problems. Next time I might try turning the Dragon microphone off my switch to zoom.  

 

This might be enough to make me enable SpeechStart+'s "MICROPHONE On" command: turn Dragon's microphone off, talk to Zoom, mute zoom and turn Dragon's microphone back on.

 

I assume that SpeechStart+ is also listening for the "MICROPHONE On" command. Why doesn't it have the same problems that Dragon's "Goto Sleep" mode command has?  Or does it?

 

 

 

 

 

 

 

 

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

This problem finally caused me to understand the reason why PCByVoice SpeechStart+ has its "microphone on" command. I now very much prefer using "microphone off" and "microphone on" (with "acknowledge switch on") to "go to sleep"/"wake up".

 

I'd still like a timeout command though. But it's much lower on my list of things to do.

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

As noted elsewhere I am trying to use a somewhat wearable Bluetooth media remote for Push to talk. It works, but the membrane button uncomforttable to hold down constantly comfortably. Although it's quite nice to just toggle on off via a button I am wearing as a ring or watchband (haven't decided which yet, trying both). quicker than microphone on/off.

if I can't get a nice PTT key, I am back to wanting a "microphone off" timeout.

Q: Is there an external script, e.g. Perl or Python or AHK, can tell what the state of Dragon is? Mic off/on, awake/asleep?

Failing that, I may just mute the microphone in Windoqws outside Dragon. That should be as good

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

Update after a month of wearing a remote on a wristband that turns Dragon's microphone on/off..


I very much like it! But...


(I would prefer a push-to-talk button on my wrist, but have not found a wearable device that can do that.)


Failing that...


Toggling the Dragon microphone on or off from my wrist is really good,


But I occasionally forget to toggle off or a few minutes, and Dragon puts the microphone to sleep after a timeout. The default timeout is one minute, but because I found that annoying I had increased it to five minutes.


Unfortunately, when Dragon puts the microphone to sleep I get all the usual bad problems described by Dragon experts in this forum: basically when Dragon is woken up from being asleep, there can be a very long wait for Dragon starts responding again, apparently processing, since asleep does not mean not listening. In addition to the annoyingly long wait, if you have said any commands during that period, and sometimes before I think, all of the usual problems with commands that get queued up occur.


So I would much prefer that the microphone was turned completely off rather than going to sleep after a delay.


Q: Is there any way to turn the Dragon microphone off after a time threshold? T

That was the question that started this for men, and since nobody has answered that question[*], assume that nobody on this forum knows of such a thing. 

Note *: except to recommend push to talk, which I suppose corresponds to a timeout of zero after the PTT button is released, does not correspond to a timeout after the last useful speech command.



Q: Is there any way to tell, from another program, whether Dragon is awake, asleep, or in the microphone off state?

If I knew  how to do this, I could write my own timeout. Well, almost.  I could poll this state  every minute or so,  but that would miss  short periods where the mic  was turned off and then on again within the polling interval.

 

Dragon's recognition history shows the timestamp of commands.  Q:  is there any way to read the timestamp of the last command from the recognition history from a different program?

 

Hmm, that gets me thinking: Is there a Dragon logfile that gets updated only when a command is actually recognized Maybe  C:\ProgramData/Nuance/NaturallySpeaking15/logs/USERS/Dragon.log? ...  So can a script can poll that timestamp, looking for changes? ... Nope, not quite.  It looks like Dragon.log is updated even when the microphone is off, e.g.  if a new app is opened, 

 

But, within Dragon.log, there are messages like

DRAGONBAR: Info: onDgnMic_MicStateChanged dgnmicOn received

DRAGONBAR: Info: onDgnMic_MicStateChanged dgnmicff received

DRAGONBAR: Info: onDgnMic_MicStateChanged dgnmicSleeping received

 

 so it looks like I can tell what the microphone state is by filtering Dragon.log.

 

 which should give me enough to create a timeout command to turn the mic off.

 

--

 

Can also filter Dragon.log for SPEECH vs NONSPEECH uterrances.  But this won't distinguish actually using Dragon, from leaving the mic on while a radio is playing nearby.

 

It might be necessary to have such a timeout command to say/ask: "The Dragon mic has been on for a very long time. Are you actually still using it?  Say blah-blah-blah if you want to continue."

 

--

 

Similarly, it would be nice to automatically disable the global PC non-Dragon mic, and video camera, if left running.  But heuristics to distinguish actual use from idleness seem to require more - at least Dragon has the SPEECH/NONSPEECH utterances in Dragon.log, which can definitely say "not in use", but which cannot reliably say "in actual use".    Asking the user may be necessary here, too.

 

 

--

 

 however, looking at Dragon.log violates good programming practice:  one should not look at a log file that is not documented, its contents can be changed at any time (or at the next software release), if there is any  better alternative.  as far as I can tell there is no better alternative.

 

 with respect to Dragon, it's just another drop in the pond:    good programming practice also says that you should not put "wait "  in a program thatt you want to be reliable, nor should you drive  other programs through keyboard commands, or at the very least keyboard commands that are relative or toggle,  and not keyboard commands  that changes based on context  that you cannot observe. 

 

But it looks like I can at least write such a program, even though it will probably break at some future Dragon release. I'm not sure if I should smile, frown, or just cry out in despair.

 

(Until  I write a script, I've had fairly good results setting the Dragon microphone timeout to the maximum, 2 hours.  So far it seems that the problems I when  Dragon microphone is on are less than the problems get when the microphone is asleep.  but Dragon microphone off is even better.)

 

 

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

This isn't the answer you're looking for but we believe it might be what you need. Rather than turning yourself inside out with a scripting or hardware solution, check out SpeechStart+. You'll find a 15 day trial in our signature tag. 1 of its features is the ability to verbally turn your microphone on when it is completely off; not just asleep.

-------------------------

Forum Mission Statement
Trial Downloads
Dragon/Sales@KnowBrainer.com 
(615) 884-4558 ext 1

I usually have one hand on my mouse and none on the keyboard when I'm working. It would be nice to be able to use one of the extra buttons on my mouse for PTT. Dragon can't assign a hotkey to do that, but it should be possible with AutoHotKey. Unfortunately, I don't know enough about AutoHotKey to do it myself.

Anyone feel like doing some coding?

-------------------------

James McVay

I already have SpeechStart+

 

It helps, but I hope to do better

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

 

---+ BRIEF

It is not very much code at all:

 

file: MButton-to-F12.ahk

MButton:: F12

 

Unfortunately, doesn't help me, since I don't have my hand on my mouse or trackball.  (In fact, using the mouse and trackball is one of the main causes of my computeritis, one of the main things that I wish to avoid as much as possible.)

 

---+ DETAIL

 

This maps the middle button on my trackball (which I happen to have configured using Kensington software to the upper left button) to F12. And I have mapped F12 as Dragon's PTT hotkey.

 

I am using this  PTT trackball hotkey right now to write this. But I won't use it for much longer, because I don't usually have my hand near my trackball.

 

Replace MButton and F12 with  whatever key your mouse/trackpad generates, and whatever key you're willing to dedicate to Dragon PTT.

 

As usual, the problem is finding a key that Dragon can understand, but you aren't using for something else. As usual, Dragon is the bottleneck.

 

Dragon has a very much more restricted set of key codes that it understands than AutoHotKey and other such software.  For example, Dragon does not seem to accept any of my mouse/trackball button keys as the PTT hotkey - not MButton, not XBuuton1, not XButton2, ...    So if those are the only keycodes you have available on your mouse or trackball, , you have to usde AHK to map one of them to one of the keycodes Dragon does accept for the PTT hotkey, as I have done above.

 

My usual  approach is to emit  a keycode that is not used by most of the software I use. E.g. function keys F13-F24  are not very often used -  but Dragon does not accept these as PTT hotkeys.  often my scripts can emit a scan code or virtual murder that is not often used -  but again, Dragon does not seem to allow or recognize any such scan code  that are not in the very small set  of standard keys.    sometimes I emit numpad keys, numpad zero from normal zero.

 

Hmm... Dragon does distinguish {Up} (which I get from Numpad) from {ExtUp} (which I get from non-numpad cursor motion keys - so those might be available.

 

Often I overload modifier+keys like LAlt+LCtrl+LiftShift+F12, which I map from tyhe media remote I wear on my wrist.  But this sort of Modifier remapping works best for transient keys, not for keys that you hold down for a long time while other keys are pressed,  whether by you, or sent by other scripts. You might be able to get away with modifier based PTP keys, but it really depends on what other keys you are sending keying from your speech commands, and how the receiving apps handle them. 

 

Oh, yeah: AutoHotKey distinguishes things like LShift and RShift but Dragon does not. So you lose that sort of  distinction.

 

---

 

 come to think of it, it might be better not to use the Dragon PTT hotkey at all: just have AutoHotKey bind the up/down of your PTT key  to a script that turns the global mic on or off.  At least this would avoid Dragon being the bottleneck, and avoid you having to waste one of the small number of keys the Dragon can bind to as a PTT hotkey.

 

---

 

But these are just the usual problems that one finds using AutoHotKey, especially to drive an app like Dragon that has a limited hotkey repertoire. 

 

They are not the reason that I'm not using the PTT hockey.

 

I'm not using the PTT  hotkey because I usual do not have my hand near the mouse or my keyboard. Nor even any of the several extension key devices I have, like the Xkey-4.

 

I am hoping to find a button device that I can wear, e.g. on my wrist or even better as a ring.   I am pretty happy with the media remote that I have found, except that it (they)  emit both the down and up events when the button is pressed down. They don't emit anything that I can see when the button is released. That is unfortunately quite common.  Also, the simple membrane buttons take too much force to press down. Indeed, I am finding that my fingers and thumb are getting fatigued using them to hold down my trackball button which is currently bound as PTT.   When I have used such long-duration presses in the past, I have found them best used with buttons that have very light touch/pressure, typically large - eg the spacebar.  

 

(Hmm, a trackpad surface that could distinguish N-finger touch might be good - But again, not for my application, I need to wear the thing.)

 

 

 

 

 

 

 

 

 

 

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

By the way, my scripts to look at stuff in the log file works. But looking at stuff in the log file doesn't work as well as I would like.

First, there is a latency of 1 to 2 minutes from Dragon events to them appearing in the log file. So it's not really useful for really short duration timeouts, like the default 1 minute. Too many races: you may have just manually toggled the mic and then back on again, when the timeout script turns it off again because your manual events have not yet appeared in the log.

It works better for longer duration timeouts, like 15 minutes. Which is great, but that doesn't solve the problem with commands getting queued up by accident, and then getting played Into the wrong place.

having the timeout script query may be right thing to do, but it's certainly damned annoying when it happens too frequently, with a short duration timeout, if the query is a human voice or a MsgBox.  It may be the sort of thing that a good bit of user interface sound design would help -  e.g. a soft tone sequence that indicates a count down to the microphone being disabled, such that I could develop a reflex of hitting the "keep the microphone on" button on my wrist. Unfortunately, while I know the theory of such user interfaces, I'm really not very good at designing the soubnd tones.

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.