Problem with Mouse Wheel messages in Ableton Live 10

Live 10 on Windows offers an option to “Autoscale” a plugin. When this option is enabled it seems the plugin window is scaled (obviously) and mouse related Windows messages such as WM_MOUSEMOVE are being modified before they are send to the actual plugin.

However the mouse wheel message WM_MOUSEWHEEL does not get the same treatment although it also carries a set of X/Y coordinates in the lParam of the message. This leads to components such as Listboxes, Sliders etc. not working correctly when the mouse wheel is used on them.

The only work-around I found so far was to store a “last known global mouse position” in doMouseMove() and using that position in findPeerUnderMouse() and getCurrentMousePos() instead of GetMessagePos().

Is there a chance that a change like this will be made to the official JUCE-version? We would like to stay on the official Github repository and not fork it but it breaks our product in one of the most popular hosts.

I also contacted Ableton regarding this issue but have yet to hear from a “real” developer.

I don’t have access to a Windows machine to test this on at the moment, but can you see if the following patch fixes the issue?

0001-Windows-Pass-LPARAM-to-doMouseWheel-to-get-correct-s.patch (3.5 KB)

With these changes it’ll pass the LPARAM through to the doMouseWheel() method so we can hopefully get the correctly scaled value for the mouse position.

Thanks for the quick reply but this won’t help. The coordinates set in the lParam value are exactly the “wrong” coordinates. Windows stores them internally and if you use GetMessagePos() you will get exactly those coordinates that Windows extracted from the last message that contained any coordinates.

This is our work-around:

Ah, I was hoping that we’d get the correct coordinates in the LPARAM… It definitely feels wrong having a DAW-specific workaround in the Windows peer code so we’ll have to come up with another solution for this. Things are pretty busy at the moment in the lead up to ADC though so we won’t get a chance to look for a few days.

1 Like

I can imagine. I am still waiting for Ableton to get back to me. No idea if my information got passed to the right person. Thanks for keeping an eye on this issue.

Short update: Ableton got back to me with some information on this. It boils down to “we are not interfering with Windows messages”.

I will take another look at the situation. It is still strange that this only happens in Live 10 and not in Cubase 10.5 which can also be put into a hi-dpi mode. Also NI Komplete Kontrol exhibits the same issues in Live 10 (mouse wheel / repaint at wrong coordinates).

I’ve tried reproducing this but it seems to be working fine for me. I’ve built the AudioPluginDemo and have tried running both the VST2 and VST3 versions in Live 10 with “Auto-Scale Plug-In Window” option enabled but scrolling the mouse wheel over the rotary sliders in the demo plug-in works as expected. I’m running the latest Live 10 beta (10.1.9b1) on Windows 10.0.18362 with a scale factor of 1.75 on the main display.

I have the same issue here, both with vst and vst3, and with the latest version of Bitwig (4.0.5) (with the bitwig option “Plug-in Interface Scaling” checked).
I couldn’t reproduce with a basic plugin yet unfortunately.

In my case the mouseWheel events are actually correct most of the time.

The problem occurs when the mouse events are passed by the mouseWheelHookCallback() that is set up in WindowsHooks.
In that case the mouse coordinates are wrong. Shouldn’t the host/window scale factor be taken into account in the mouseWheelHookCallback() ?

I’m not sure when/why the mouse events are passed though this hook sometimes (some kind of focus reason?). I couldn’t find a way to get that behaviour with a basic plugin.

The problem occurs when the mouse events are passed by the mouseWheelHookCallback() that is set up in WindowsHooks .
In that case the mouse coordinates are wrong. Shouldn’t the host/window scale factor be taken into account in the mouseWheelHookCallback() ?

Does that ring any bell?
Is this WindowsHooks still needed at all?
not sure for @reFXmkamradt, but simply removing it seems to solve the issue here.