request: allow faster triggering of "rest n tap one"

[hbak]

There seems to be a period of ~1/3 of a second after resting n fingers where tapping one doesn't trigger the action. I have to intentionally delay that second input in order to trigger the action. I'm humbly requesting that you decrease or eliminate that dead period. It's the only thing holding this app back from Jitouch-level "it just works" fluency, for me.

I don't know if this is a feature request, bug, or limitation, so I've put it here instead of "Issues". Thank you for creating a beautiful and functioning alternative to BTT, it's life-changing!

[rxhanson]

This gesture is the hardest one to “get right” from my side but a lot of users appear to gravitate to it. I have plans to dig into it again for the next release, can I send you a prerelease to try out when I get to it?

[rxhanson]

(Rather, I’ll post a link to the prerelease here so that anyone can try it out and provide feedback)

[rxhanson]

Apologies for the delay, I finally got a chance to look back into this.

It would help me to know - have you tried setting the "Touch Precision" to Low in the Settings tab? Does that make any difference in how you perceive the gesture?

[hbak]

It doesn't make any difference I can perceive

[rxhanson]

Thanks! Here's the first adjustment, let me know if there is any improvement.

https://www.multitouch.app/beta/multitouch1.26.5.dmg

[hbak]

"Double Tap" is not checked.
I'm 100% up for doing whatever may be necessary. I thank you and would understand completely if this ends up not feeling like it's worth your attention.

rest one tap one: three fast trigger failures, then a success.

2022-03-01T10:39:30-08:00: Potential incorrectly blocked click
2022-03-01T10:39:32-08:00: Potential incorrectly blocked click
2022-03-01T10:39:33-08:00: Potential incorrectly blocked click
2022-03-01T10:39:33-08:00: Gesture matched: onePlusLeft

[rxhanson]

What do you have your rest one tap one configured to execute?

[hbak]

apps with tabs: switch tabs left|right. I tried changing it to a few different things and the debug log shows the same behavior. A note: this time around when viewing the logs I noticed that every "Gesture matched" log entry is also accompanied by the "Potentially incorrectly blocked click" entry at the same time.

[rxhanson]

Right, so I think the root of your issue comes down to tap-to-click and how Multitouch handles it. Tap-to-click will execute a click where the down-click is indistinguishable from an actual click. Multitouch has to prevent the click in order for the tap gesture to work properly, and there is complexity in doing so. I still have more testing to do, but will post back when I have something worth trying.

[rxhanson]

Sorry for the delay. I've given this one a decent amount of thought, and I think my preferred route is actually to implement tap-to-click within Multitouch, and that way I can easily know and ignore tap-to-click when necessary depending on the gesture. Also, Apple has changed tap-to-click slightly in some macOS releases, which has broken some of the Multitouch functionality in the past. The plus side here is that it will just be a better user experience all around to have this in Multitouch, but the down side is that this isn't going into an immediate release and it will take me some time to get it right since I'll have to implement the drag lock stuff along with it that's in macOS. There's also the risk that your issue is not actually only dependent on tap-to-click, but it seems likely to me, and either way I would prefer to isolate future issues like this by providing tap-to-click within the app.

[hbak]

This seems like... an insanely difficult endeavor. I just tried your new tap-to-click option and I was having issues with my palms selecting the text I was writing and overwriting it. A long time ago, when I was attempting to mess with the trackpad/multitouch API myself, I saw there were some interesting things you could see such as the rotation of a finger on the trackpad. I don't remember if there were things that would directly assist in palm rejection, but if you end up wanting to implement it yourself... I feel for you.

[rxhanson]

Thanks for trying it out. Did it affect your rest and tap triggering at all, despite the accidental tap-to-clicks?

[rxhanson]

Also note that in order for multitouch to not perform the tap to click rejection, you would have to first disable it in sys prefs then restart multitouch.

[hbak]

it didn't make any difference for rest+tap triggering. The debug log had no "potentially incorrectly blocked click" messages. No message came up when attempting a "fast" rest-one-tap-one.