PTT/keybindings to F13-F24 about mumble

[SuperFlue]

Since i am still subscribed to this....

F13-F24 works on the newest snapshot, tested using an Ardunio chip with the HID Project library to send a real USB HID key code.

Key binding shows up as "k:" but is otherwise working.

[mkrautz]

I can reproduce this when Mumble is run in with uiAccess=true (making Mumble an UI Automation client).
Mumble is run in this mode when installed into Program Files, or Program Files (x86).

But if I copy my Mumble installation to my Desktop, and run it from there, it works fine.
(Running Mumble outside of Program Files causes UI Automation to be disabled).

I tried binding F1 to F13, using the script provided by @Etuldan.

When running Mumble like this, the shortcut name in the shortcut settings is simply K:, because my keyboard doesn't have an F13 key.

But the shortcut itself works just fine.

Can anyone subscribed to this issue see if this workaround works for them?

1. Copy the Mumble directory from c:\Program Files\Mumble or c:\Program Files (x86)\Mumble to your desktop.
2. Run Mumble from your desktop.
3. Try using your F13-F24 key in Mumble.

Thanks.

[mkrautz]

Can people please retry this with the latest snapshot?

WinX64: https://dl.mumble.info/mumble-1.3.0~2569~gd196a4b~snapshot.winx64.msi

We just fixed @darkuranium's problem with F13.

If it doesn't work at first, you can also play with the option "Enable shortcuts in privileged applications" in Settings -> Shortcuts -> Additional Shorcut Engines.

Thanks!

Sourceforge forgot the DXdiag file.

Still does not work in the official 1.2.4 release.

The following attachments were added on the original comment:

• https://sourceforge.net/p/mumble/bugs/_discuss/thread/9eb82093/697a/attachment/DxDiag.txt

Still exists in the official release.

This still exists in the latest Windows snapshot builds (as of 1.2.4-119-g325226c).

I noticed some interesting behavior on my PC. I bound F13, F14, and F15 to PPT and whisper keys several versions ago (back when they still worked). As I updated, I lost the ability to assign any functions to the F13-F24 keys, but I was able to use my old binds.

Interestingly, the binds only triggered when the mumble window didn't have focus. If I had the mumble window selected and tried to transmit, nothing would happen. Also, If I was transmitting and brought the mumble window back into focus, my key would "stick" in the transmit position.

Unfortunately, my binds were mysteriously wiped recently (perhaps another bug?) and I can't reassign the keys, so I can't do any more testing with F13-F24. I even tried going back to 1.2.4 beta 49 to no avail.

[SuperFlue]

Is there any work in progress to solve this issue? Or have this issue simply been forgotten?

[hacst]

Considering it isn't assigned to a milestone/dev I'd guess no work in progress ;) The tracker doesn't forget though but at least I wasn't aware of this issue. Do you happen to know in which exact version it stopped working in. I don't have any keyboard with >F12 so I'm not sure how I would go about reproducing this. What kind of keyboard are we talking about and does it require drivers by the manufacturer?

[SuperFlue]

I myself have not used these keys in an earlier version, only thing to go off is the information in the earlier posts.
When it comes to the keyboard I am using It is a Logitech G710+ but I stumbled upon a little Java program that sends these keypresses and have used this to map my macro keys to these function keys. Here is a link to the program in question (there is a link to the sourcecode for the program also):
http://www.overclock.net/t/1453680/razer-naga-real-side-buttons-trick-f13-f24-bound-to-side-buttons.
(Note that you may have to run the Java program with administrator rights for it to pass the keypresses properly).

[NahmiiVuhuni]

Accidentally duplicated this before, but the issue seems to still persist in 1.2.8 and 1.3.0 development versions. Only tested on Windows 8.1, but Mumble simply refuses to accept the F13-F24 keys as a key in shortcuts.

[GuiSim]

I was able to reproduce this issue in 1.2.8.

[Volatar]

This issue persists currently as of the 1.3.0687g9c462ce~snapshot.

[forivall]

@SuperFlue as far as the g710+ goes, #1730 should be able to take care of that problem.

[Volatar]

Not everyone has access to the G keys. Everyone can bind F13-24 though. (Heck, you can find keyboards with those keys if you look hard enough.)

[forivall]

@Volatar I'm not claiming to solve this problem at all 😢 just enough for logitech users to get by 😠 . I don't know directinput well enough have the patience to wade into the mess that is directinput to want to debug this issue.

[mkrautz]

@Volatar

Which program do you wish Mumble to receive these keys from? Autohotkey?

Having a reference in here should allow anyone picking this bug up to have a way to reproduce the issue.

[jkluch]

Mumble receiving keybinds from Autohotkey would be ideal because AHK opens up many options for macros. Mumble DOES acknowledge ahk binds if ahk is run as admin but mapping F13 won't map. Using the exact same script will map F12 so I'm not sure what the issue is. I used to be able to map F13 on Mumble v1.2.3 and I had a ticket found here. where I mentioned it. I recall someone saying that the keybind code didn't change between 1.2.3 and 1.2.4 but something changed there, possibly a dependency? I'm not really familiar with C++ or the codebase so wouldn't know.(After some testing I'm not sure this is the case anymore) Upgrading to 1.2.4 from 1.2.3 keeps previously entered F13 keybinds (which is what my ticket was about, a snapshot version broke the bind) but the bind just shows as "K:" not "K:F13" kinda buggy.

My current script is just running:

#NoEnv
#InstallKeybdHook
SendMode Input
sleep, 4000
SendInput {F13}  
ExitApp

Something else that just occurred to me that might be related. The F13 bind never worked while Mumble is in focus I don't know why, but that could be the reason it won't bind.. because it doesn't work with mumble in focus.

[forivall]

Perfect! When I have the time, using that information, I'll be able to perform a git bisect to figure out exactly which commit broke it. Personally, looking at the difference between 1.2.3 and 1.2.4, it could be a number of different changes that had this unexpected side-effect.

[jkluch]

Before you go through the trouble let me roll back my Mumble to 1.2.3 and verify that autohotkey works for setting the bind. This was 2 years ago and I recall using an old version of Logitech's setpoint software to bind F13 to my G500 mouse button. I can't remember if I had to set the bind on Mumble with ahk or my mouse. Not sure if that little detail matters or not since I do know that binding at all was doable in 1.2.3 but not 1.2.4. I'll update once I figure out how I did it.

[forivall]

Yeah, I use this script in the logitech gaming software (LGS), and when I was doing some research for the native g-key support (and research for a teamspeak tool+plugin), I did discover that the f13-18 generated by LGS were being recognized by the nil library test program.

Don't worry, I'm not going to start working on this for a few days.

[jkluch]

Ok so I was completely wrong about 1.2.3 working but anything after that not working.. my bad. Getting it to work required a bit of tinkering and I guess I never figured out the exact setup that worked. You can map F13 on the current version of mumble the same way you can map it on 1.2.3 and it can be done with just ahk. In order to set the hotkey I needed two scripts running as admin.
In this script I bound a key on my keyboard to F13.
Using the below script by itself doesn't really work, if you try to set the shortcut by pressing 'o' mumble just sits there waiting for a button push as if you haven't clicked anything. If F13 is already mapped then 'o' will act as a shortcut.

#NoEnv
#InstallKeybdHook
SendMode Input
o::F13

Now.. if you keep the first script open and running and use this script which sends an F13 keypress on a 4 second delay (so you have time to start the script then click the shortcut area in mumble) then you can set F13 as a short cut.

#NoEnv
#InstallKeybdHook
SendMode Input
sleep, 4000
SendInput {F13}
ExitApp

This second script isn't needed if you already have a macro button or whatever mapped to F13, you can just use that button instead of the second script.

[Volatar]

I have not been using AHK. I was using the little Java app that @SuperFlue mentioned earlier to bind extra buttons to F13 and friends. Unless I am mistaken, the results should be a native windows keypress of F13, nothing crazy, nothing scripted, just a normal keypress. And said keypress does not work on the current version of mumble.

[Volatar]

A quick test of using the Java app to send F13 to mumble's key configuration instead of pressing my macro did not result in success by the way.

[jkluch]

@Volatar Are you having trouble mapping F13 in mumble or are you having trouble using an existing F13 shortcut in mumble? If you're unable to map the key, try the method below:

Do me a favor and install ahk. create a file named something.ahk with the contents

#NoEnv
#InstallKeybdHook
SendMode Input
o::F13

This will map the 'o' key (just a random key) to F13. After you run that script try to use your Java app to add the shortcut. If it works you can then stop the script by closing the program in your notification tray and you should be able to use your Java app without needing the ahk script.

If that doesn't work create the second script like I mentioned in the post above yours and try that.

I'm trying to figure out if there's some logic being done to check for an F13 key before allowing the bind and if by using the AHK script you're tricking mumble into thinking there is an F13 key.

[Volatar]

@jkluch "Are you having trouble mapping F13 in mumble or are you having trouble using an existing F13 shortcut in mumble?"

Both

I shall try your directions momentarily and return and report.

[Volatar]

Running the first script and then attempting to configure mumble using the Java app did not work. (Though the script was doing something. Had to stop it to type the letter o here.)

Note, your statement here is false for me: "Using [the first script] by itself doesn't really work, if you try to set the shortcut by pressing 'o' mumble just sits there waiting for a button push as if you haven't clicked anything."

What happened when I tried that was that mumble accepted the keypress as the normal press of the 'o' key. This push to talk key configuration did NOT work when I then tried to use it. It simply would scroll through anything starting with 'o' on the server and did not execute push to talk, even with Mumble not focused.

For testing, I opened up Teamspeak 3, which I already have configured to use F13 as push to talk, and with that first script running it did not register 'o' as F13, but also took it as the letter, executing its standard behavior of selecting the first thing in the server starting with 'o', much like Mumble.

I then tried configuring TS3 with the script running and, like Mumble, it took the keypress as the letter 'o' (while an actual input of F13 to TS3 shows up in the configuration screen as '124'). Unlike mumble, this configuration of 'o' as PTT (AHK script still running) DID work as push to talk.

Trying second script and your directions now.

Second script did not behave as instructed. Mumble acted as though no key had been pressed at all, just as it does with the Java app and my configured macro. Teamspeak blipped though. It got the F13 press, so the script works. I then closed TS3 to make sure it was not interfering in any way and got the same results with Mumble.

I suspect it might be possible that your first script is doing something wrong? The fact that when it is running, neither Mumble nor TS3 recognize pressing 'o' as F13, yet Chrome does (as I cannot type the letter 'o' with the script running), seems.... weird.

[jkluch]

Just to be sure did you launch these scripts as admin? It doesn't sound like it. You need to right click the file, then press the "run as administrator" option like so:

I'm at work right now but I'll try that java program once I get home too.

[Volatar]

I did not use that option. Let me try that...

Ah ha! Script 1 had no different behavior and did not allow me to use the Java app to send the key to mumble, but upon utilizing the two scripts together (run in admin mode), Mumble detected the F13 press from script 2. The shortcut shows up blank, but both 'o' while script 1 is running, and my mouse macro to F13 now work as push to talk in Mumble.

I think we are getting somewhere! :)

[forivall]

If you run the java app as admin, does that work?

[Volatar]

I do not know how to run a .jar as administrator.

(Windows 8.1)

[forivall]

if you know how to run cmd as administrator in 8.1 (I use 7, so 🤷), do that and then try java -jar <path-to-jarfile>. Hopefully java is in your %PATH%. Or else you'd have to do <path-to-java> -jar <path-to-jarfile>. 😭

[Volatar]

Opening cmd in admin mode is as easy as right clicking the start button in 8.1. One of its redeeming features for a power user I guess.

Tested. No change. Did not work. Hmmm...

[andrewpmartinez]

This works in Mumble 1.3.0867g197f13e~snapshot 64bit, on Windows 10 64bit.

The key binding will be displayed as "K: " instead of "K: F13".

[Etuldan]

Don't know why, but suddenly (after computer restart), mumble lost my PTT setting to F13, and I'm not able to set it again (keybinding not recognized), nor with an AHK script, nor with my already configured Logitech mouse.
I tried also to upgrade my mumble installation (from 1.2.12 to 1.2.13, both stable) without success.
Windows 7 x64

[forivall]

I'm mostly curious, but could anyone who's still having this problem see if it's detected by https://github.com/forivall/niftykb/releases? <- program where I pulled out mumble's keybinding code into a standalone app. This way, we'll know if it's a problem with the keybinding code itself, or something else in mumble is interfering with the keybinding.

[Etuldan]

@forivall "This application failed to start because it could not find or load the Qt platform plugin "windows" ".
I unzip all the content (including the QT5 related DLLs) from https://github.com/forivall/niftykb/releases/download/v0.1.0/niftykb.zip (even with QT 5.5.1 installed)

[Volatar]

This issue persists on 1.3.0970g888a459~snapshot for win-64 on my Windows 8.1 64 bit machine.

I was unable to make your program work @forivall.

[Glockshna]

I was able to bind F13 through my Logitech Gaming Software to mumble on windows 7 but since I switched to Windows 10 Mumble no longer recognizes the key. It still works fine in Teamspeak though. Really getting frustrated with this =/

[Etuldan]

Found something new that may be interesting:

I need to run my autohotkey script which redirect a random key (F1) in my case to F13, in order to mumble accept any F13 key (simulated by my autohotkey script of by my Logitech mouse)
Without this script, even if I press on my F13 button on my mouse, I can't configure mumble nor use the previously PTT configured function.
All is OK w/o the autohotkey script running for teamspeak for example (they have both the same key bind)

So, here is my conclusion:
By default, as my keyboard don't have this F13 key, mumble won't accept it from any device, even if it works for other software. As soon as I add this key (with the autohotkey script), mumble will accept this key.

I'm therefore not 100% sure about this, I'll continue to inspect on my Win7 64b installation.

Edit : More info:
I have to run the AHK script, and open mumble to do the trick, then close the AHK script. If on a new windows 7 session, I start the AHK script, close it, then open Mumble, it won't work.
The script is
F1::F13

[Keridos]

Doesnt work for me in mumble-1.3.01797g6ac0553~snapshot.winx64 on windows 10 64-bit. Even with the client being run from my desktop it does not work.

[zkxs]

Using Mumble 1.2.18 on Windows 7 from the MSI, I can successfully use F13 as PTT. This is with Mumble installed in Program Files (x86).

I used this .reg file to rebind Caps Lock to F13. Worth noting is that even though the shortcut bind works as expected, it is displayed as K:Caps Lock. With the same setup but in Discord, the key displays as F13, so there is definitely some way of discerning the correct display name.

[Keridos]

I have additional info. In all versions I tested it sporadically works, but after a pc restart I have to reset the keybinding and I do need to start autohotkey and use that to map another key to f13. After i used that I can use my mouse button that works as F13 as intended. This is the same in uiAccess enabled and disabled.

[crimsonblod]

I am also having this issue in all versions shown here. And binding one of the keys on my keyboard to trick mumble into accepting f13 as an input doesn't work either.

Just figured I'd mention that this is still an issue, because it's been a few months since the last update here.

[jkluch]

Have you tried what I mention above?
I think you only need one script but according to what I wrote above I used two so try two.
Using ahk create two files, like these, they bind 'o' and 'p' to F13

f13_o.ahk

#NoEnv
#InstallKeybdHook
SendMode Input

o::F13

f13_p.ahk

#NoEnv
#InstallKeybdHook
SendMode Input

p::F13

• If you have autohotkey installed you should be able to right click your scripts and run as administrator, if you run the scripts with lower privileges the bind won't be recognized in mumble.
• Once both scripts are running open mumble's shortcut settings and in the shortcut box press 'o' or 'p' you should see "K:" without anything after it. This is a bug in mumble but it means the bind worked.
• Mumble has another bug where the F13 bind doesn't work while the mumble window is in focus so click off of the mumble window before testing.

[darkuranium]

@mkrautz: Tried it. Doesn't work from the desktop, either.

FWIW, TeamSpeak and Discord are both installed in Program Files, and F13 works fine there. I don't use Ventrilo, but apparently, F13 works there, too.
Mumble is the only major VOIP software where it does not work, so I doubt the problem is anywhere but in Mumble.

[PaletzTheWise]

Tested on https://dl.mumble.info/mumble-1.3.0~2586~g894ade2~snapshot.winx64.msi and https://dl.mumble.info/mumble-1.3.0~2586~g894ade2~snapshot.msi.
Both works with F16 generated by AHK.
I also tested with my mouse using Logitech gaming software where I bound F12 to mouse 4 and then edited the profile xml file to change it to F16. This works as intended with Teamspeak and x86 Mumble. However x64 Mumble detected mouse 4. In fact the mouse button was capable of clicking on Mumble UI elements.

[crimsonblod]

I'm still on 1.3.02569gd196a4b and it's working for me on this build. If the link works the same way, this in theory should be the link to it. No promises though. If it's the right one, you should try it and see if your mouse works with it.
https://dl.mumble.info/mumble-1.3.0~2569~gd196a4b~snapshot.winx64.msi

[PaletzTheWise]

After a bit more testing looks like there is no difference in x64 and x86 since I have observed both versions become aware of physical mouse buttons. When it happens Mumble behavior depends on whether it is in focus or in background. It detects physical mouse buttons when focused, ignoring the F16 configured in Logitech gaming software. When in background it is the other way around, it detects the F16 and does not detect physical mouse button being pressed. This means I can use the AHK to configure a short-cut for F16 and then use the mouse-generated F16 once Mumble is in background.

I have not seen this physical button awareness in Mumble 1.2.4. The interesting part is that two days ago the x64 version was always aware, today the x86 version is always aware. This persists through Mumble restarts. Maybe it's down to which version I ran first. Finally, this awareness is not tied into F13-F24 since it affects other keys as well.

[Eforen]

I too have this problem

[Krzmbrzl]

I'm closing this issue in favor of #4467 as it seems that the original issue has been resolved anyways.