Old 10-19-2020, 10:48 AM   #1
mks
Human being with feelings
 
Join Date: Dec 2011
Posts: 171
Default Windows touch delay problem

It seems that there is a specific problem using a touch display on Windows 10. For instance, grabbing a fader does not take effect (nor does it register as being touched) until you have moved a significant distance. Obviously this is problematic for various reasons. Especially when automating. Resulting in touch mode being ineffective and writing automation with huge jumps.

This is true for all parameters I've tried. Volume, Pan, plugins, etc.

It does not happen in other native areas of the OS like the sound control panel slider, etc. Though it does happen in other applications such as RME Total Mix. I've also disabled things like touch-hold for right-click.

It does not happen with mouse input.

Is this the case for others using touch displays? Unfortunately, this makes for completely unusable touch interaction. Something my current work environment is built around

Last edited by mks; 10-19-2020 at 06:03 PM.
mks is offline   Reply With Quote
Old 10-19-2020, 02:18 PM   #2
mks
Human being with feelings
 
Join Date: Dec 2011
Posts: 171
Default

To add to that with another strange behaviour (that hopefully means this is a fixable thing to a degree): While I noted that touching a parameter does NOT instigate "touch" automation. The pair of points are immediately generated upon REMOVING your hand from the touch input. Super weird.

I also came to a conclusion that this has something to do with Windows Ink creating a mess. For instance, on my Wacom display, I can choose to disable Windows Ink for pen input. With it on, the same problem persists. With it off, it goes away. There is a "deadzone" of movement that needs to be exceed (say around 30 pixels). So, I'm not sure if this is circumventable at the program level. I sure hope it is since unfortunately this makes Windows Touch completely unusable for any of us. The OS seems to be able to get around it, but my fear is that the click isn't passed through until this "deadzone" is exceeded.

Last edited by mks; 10-20-2020 at 05:20 AM. Reason: More detail
mks is offline   Reply With Quote
Old 10-22-2020, 05:28 PM   #3
mks
Human being with feelings
 
Join Date: Dec 2011
Posts: 171
Default

Please help.

So I've done a bunch of testing on other systems and configurations. There is an inherent problem with the way Windows handles touch/pen input. Though there is clearly a way for developers to get around it, this really shouldn't be a stumbling block at the OS level in the first place.

I've created an issue with MS feedback and hopefully we can get some upvotes on that issue in the hopes of getting it fixed. Please see here if you have the time and care about this. These votes issues do sometimes get addressed: https://aka.ms/AAa1dta

To summarize :
Performing a click-drag action with a stylus or touch does not register (as a click nor a click-drag) until a certain "deadzone" of movement is surpassed. This causes a complete inability for small and accurate adjustments. So no ability to make the subtle adjustments we need. And no way to go into touch automation parameters on anything. This also eliminates the ability to simply touch and hold a GUI object since the click does not register as a click until release. Again, an issue for writing touch automation.

The OS GUI overlay clearly recognize the inputs and immediate movement. Unfortunately they do not pass that on to the underlying program, instead imposing this "deadzone" behaviour. There's also evidence that the OS even makes exemptions on this for itself since it's obviously not desirable in instances where accurate manipulation is necessary. For example: dragging a slider in the Sound settings panel reacts immediately. Test show this may be tied to Windows Ink.

This behaviour needs to be removed or made globally optional for many programs to work as intended.

Maybe Cockos can tie into the API/Library/whatever to make this work regardless though (as others seem to be able to) since I'm not holding my breath with MS development.
mks is offline   Reply With Quote
Old 03-27-2021, 12:20 AM   #4
X. O. Apodo
Human being with feelings
 
Join Date: Sep 2012
Posts: 122
Default

Sorry if this is too far off topic.

I am having an issue with the mouse pointer and the multi-touch monitor. When I touch anywhere on the multi-touch screen the mouse pointer jumps to the touch location.

I understand that the first finger touch is converted to a mouse event. Is there a way to fix this? Searched for a solution but mostly found others that have the same problem.

Unfortunately in Windows the mouse pointer and the finger touch are linked. Now how to de-couple them, make them independent with one another.

Check this out:
Multi-touch finger touch and mouse pointer incompatibility! Weird!
https://www.kvraudio.com/forum/viewt...&hilit=pointer
__________________
Multi-touch Monitor, XotoPad 2 and iPad Air as Midi Controllers, iConnectMIDI2+,
Windows 10 64 bit, Reaper 6, Waves Horizon, Komplete 12, Iris 2, Some Melda, PSP, SonoKinetic, Eventide, Blue Cat Audio, Homegrown.

Last edited by X. O. Apodo; 03-27-2021 at 12:26 AM.
X. O. Apodo is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:35 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.