Unable to assign F13 as PTT key

[neilenns]

To reproduce:

1. Use the FootSwitch app to configure your foot pedal to send F13 when pressed
2. Run VectorAudio, open settings, click Select New Key
3. Press the foot pedal

Result: VectorAudio appears to detect a key input, as the button reverts back to Select New Key, but the assigned key still shows as Unknown. Expected result: F13 gets mapped as the PTT key

Screenshot from FootSwitch:

I am able to map F13 in Discord fine using a similar method (hit the Edit keybind button then press the foot pedal, it is detected properly by Discord).

[neilenns]

I noticed a few other issues opened about assigning F13 and those issues said F13 should be supported, but at least in this case it isn't working.

[pierr3]

I need to look into this again, it's supposed to work but clearly does not.

[neilenns]

I poked around the code a bit and didn't see anything obvious. I'm not set up to build C++ apps on Windows so I couldn't pull the code and add some logging to get more info. Let me know if you want me to test anything on my end/try a build that has more logging of what scancodes are getting received.

[pierr3]

Can you try this build?

[neilenns]

No change.

(FYI Windows Defender blocked the download of the build saying there was a virus in it. I've had the same false positive in some of my own apps before, never figured out why.)

[pierr3]

Pretty expected for the debug build to be flagged as something weird. I am a bit lost since the latest commit essentially uses any available pathway for key detection. I think it might just be an issue with SFML, which we might need to just get rid of.

[neilenns]

I wrote a super quick and dirty C# test app using SFML.NET:

        window.KeyPressed += (_, e) =>
        {
            if (e.Code == Keyboard.Key.Unknown)
                return; // Ignore unknown keys

            Console.WriteLine($"Key Pressed - Code: {e.Code}");
        };

When I press the foot pedal I get this output:

Key Pressed - Code: F13

[neilenns]

I uninstalled VectorAudio and reinstalled the debug build just to be 100% sure I wasn't running the wrong version. Definitely doesn't work.

[pierr3]

Hum so it seems it got the key but not the scancode, let me review the code I did because it should do exactly that

[pierr3]

Oh, could you check your log file? The debug build adds a bunch of messages that could be useful

[neilenns]

Oh, could you check your log file? The debug build adds a bunch of messages that could be useful

How can check and make sure I'm running the debug build? Despite uninstalling, disabling Windows Defender, and installing the build from above, I'm honestly not sure I have the debug build. The log file is attached, as you can see it's boring and doesn't have anything new in it.

vector_audio.log

[pierr3]

Can you try setting a new PPT key, and then checking the log file? There should be output in there, normally

[neilenns]

Can you try setting a new PPT key, and then checking the log file? There should be output in there, normally

I just did again, with a fresh install of the build from the link above to an entirely separate folder than the previous install. Log file still doesn't have anything new in it after attempting to set the PPT key.

vector_audio.log

[neilenns]

The timestamp on the exe is 3:10pm local, which is about right according to GitHub (the release page shows the build 3 hours ago)

[pierr3]

Thank you, then I'm not too sure what this is, since it seems like it does pick up your key's scancode properly, but somehow is not able to display that the code is valid. Question, did you try to actually use the PTT? Despite the settings showing unknown, it might actually work.

[neilenns]

I'll give it a go, just have to find a friend to spawn at an airport and let me know if they hear me talk.

[neilenns]

Well, we spent a lot of time spent chasing down the wrong issue 😅

You are correct, it does actually assign the key, it's a display issue with the "Key: Unknown" label. I also tried with the released version (1.5.0), same thing. It doesn't reflect in the label but does work when I use it.

Updated the issue title accordingly 😬

[pierr3]

You're the best, thank you for finding this out! Just gotta fix this now

[pierr3]

I've implemented a fix, unfortunately I did not find a way to get the key name, but will just display that the key is set, hopefully that does it for now.

[pierr3]

I also opened an issue in the upstream library, if you want to add context: https://github.com/SFML/SFML/issues/2872

[neilenns]

Interesting that it's an underlying library issue. Your bug report to them was great, even with a code sample. I wonder how responsive they are to fixes.

[pierr3]

This has been fixed upstream, I'll implement a temporary patch waiting for the next release of SFML

[neilenns]

Wow, they were FAST with the fix! Interesting root cause too.

[pierr3]

Yes, it's not the first time I report a bug to them and they always were very helpful and fast! Surprised nobody had reported this yet though, but then again no surprise this is a funky Win32 issue in the end.