Standard tap+hold mapping arrangement not behaving as expected/as it did in pre-fork antimicro

[instinctualjealousy]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

(This absolutely is a greater "issue" with input handling as a whole as it's related to timers on the programmable functions. It's even possible that AntiMicroX's behavior is "more correct", even if it results in profile breakages. It's possible this only applies to Windows. I'm just putting this up here for posterity.)

Discussed here on the old antimicro wiki. In the above-mentioned pre-fork- it works as expected. In AntiMicroX, the Tap part of the Tap+Hold isn't registering consistently. This is true across more than a few games I've tried. It's quite irritating when I go to Tap the start button and it fails to register some (or most) of the time. Hold works fine.

This is a common arrangement I use in my profiles to make single buttons do two things:

<slots>
    <slot>
        <code>300</code>
        <mode>hold</mode>
    </slot>
    <slot>
        <code>0x1000000</code>
        <mode>keyboard</mode>
    </slot>
    <slot>
        <code>10</code>
        <mode>release</mode>
    </slot>
    <slot>
        <code>0x1000004</code>
        <mode>keyboard</mode>
    </slot>
    <slot>
        <code>290</code>
        <mode>release</mode>
    </slot>
</slots>

The most common thing I do is an Enter+ESC combo button. This is helpful with some PC games. I can move forward with a start button Tap, and I can go back/open the ESC-mapped pause with a start button Hold. I usually pair this with a D-Pad Arrows mapping, but that's not important for this issue.

I raised the values to the ones listed in wiki (290 to 490, 300 to 500) just to be "safe" and it didn't fix it in AntiMicroX. I believe the problem is with the 0.01s Release window used between. A keyboard testing app does show Enter being pressed every time on Tap. My guess is some games are less tolerant of these values/how AntiMicroX parses them.

Expected Behavior

It should behave like pre-fork antimicro and games should be able to see a 0.01s Tap release of whatever desired key without issue.

Steps To Reproduce

1. Program a hold pattern like above
2. Try various games or programs with the desired Tap key (read documentation to understand function) to see if it's registering appropriately
3. It may or may not work for you, or it may work sporadically (in my testing) where it sometimes does/sometimes doesn't register

Environment

- OS: Windows 10 22H2
- AntiMicroX version: 3.3.2

Anything else?

I can probably work around this by finding the new tolerances for a Tap release window- and doing some find and replace on all my *.amgp profiles (trying to avoid false positives).

Edit: Tried it in Soul Reaver 2 with 0.02s and 0.28s Release and Hold (the last two values). Didn't change anything... maybe made it slightly worse. I then tried an extreme difference (0.1s Release and 0.2s Hold) and it made it way worse. With regular speed Taps, it wouldn't register 90% of the time. If I lagged my press a bit (kept it held for a few more microseconds), it was more likely to register. I am starting to think this is broken and does need fixing. Either that, or this actual Tap+Hold routine needs to be completely rewritten on my part for idiosyncrasies in its routine handling.

---

Upvote & Fund

• If you find this issue important, mark it with 👍. It lets us see which fixes and features are demanded by the most users.
• We're using Polar.sh so you can upvote and help fund this issue. It may incentivize some developers to contribute to this project and fix some bugs.
• Funded developer receives the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.