Remote Desktop and Gain Sliders

Does anyone access Cantabile via Microsoft Remote Desktop? If so, do your gain sliders in Cantabile work properly? Mine “snap” to center on drag instead of dragging from their current positions, and I’m wondering whether that’s normal.

My versions: Microsoft Remote Desktop (v10.2.3012.0) to access Cantabile (Performer 4187 x64), with both systems running Win 11 Pro 23H2


I use RDP when I’m in the studio to access my GIGPC and can’t say I’ve seen any issues.

Thanks, @Derek. Here’s what I see:


Note that as soon as I start to drag the slider, the mouse arrow jumps back to the original small slider instead of staying on the zoomed slider where it belongs. This causes the zoomed-in slider to jump the gain to some center-ish value (around -9db). As a result, it’s hard to make small adjustments to anything. This only happens over RDP.

Your RDP connections don’t do this?

I just tried it this morning and and it is working fine over RDP - I am not seeing what you are seeing.

This is on Cantabile Performer 4187 on my GIGPC which I just put on this morning (was also fine on the old Cantabile build that I had this morning - 4154 from memory) and Remote Desktop on my DAWPC PC is 10.0.19041.4355, with both PCs running on Windows 10 22H2 19045.4412

Not sure if that helps. I

1 Like

Thanks, @derek. Yes, that’s helpful info.

Since you’re on Windows 10, I wonder whether this is a Win 10 vs. 11 problem. Maybe someone who uses RDP on Win 11 will see this and do a quick test…?

After doing some more research, I have a theory and some suggestions that maybe would interest @brad:

Most newer Windows RDP clients (including Microsoft’s) now apparently enforce “absolute mouse mode”, where the client renders the mouse instead of the host, and the client sends absolute mouse coordinates to the host desktop. This unfortunately breaks Cantabile’s gain sliders, because host-side mouse-jumps don’t persist (they aren’t transmitted back to the client). As soon as the user moves the mouse to drag it, the mouse arrow therefore jumps back to where it was before the host-side jump, jumping the gain slider with it.

I can think of two ways Cantabile might gracefully dodge this incompatibility:

  1. What if the zoomed gain slider were changed to open overtop of the zoomed-out one instead of below it, always positioned so that its slider circle starts directly under the current mouse position? I can’t think of any disadvantage, and it would avoid any need for a mouse-jump.

  2. Alternatively, maybe there could be a right-click action on gain sliders that opens the zoomed view with an X-close box on it. The user could then move the mouse down to the zoomed view, avoiding the mouse-jump problem, and use the X-close widget to close the zoomed view when done. This would also open the option of non-drag actions on the zoomed view, such as clicks to jump the slider to a particular spot, or cursor keys to adjust it by some fine increment (e.g., 0.1db), which some users might appreciate when fine-tuning gains.

Just my thoughts.


Hi Kevin,

Thanks for reporting this. I wasn’t aware of issues with the mouse repositioning of RDP, but I’m also not surprised.

I’ll have a think about how to better handle this. In the meantime, there’s a possible fix for RDP mentioned here.

Logged here.


Thanks, Brad.

Unfortunately, the RDP fix you linked only works on certain versions of Windows 10. Windows 11 users are out of luck. From the Microsoft blog posts I saw, it sounds like they abandoned all relative mode support after Win10 because absolute mouse mode performs so much better.


Hi @Hamlen,

OK… leave it with me.

The other approach that might work in the meantime is to just use the keyboard… click on or tab to the slider, then press enter - you can then use arrow keys, home, end, page up/down and the mouse with the popup displayed.


Hi Brad — Thanks for this! I didn’t realize there was a way to open the popup without mouse-dragging the slider. Selecting the slider by directly clicking on it unfortunately backfires (because it launches the popup and mouse-jump), but if I click on some other element of the row, then tab over to the slider, then press enter, it works.


You shouldn’t need to tab - just click on it which will popup/disappear, but should the leave slider focused so you can then hit enter.

The “popup disappear” action triggers the incompatibility though. The popup appears and the mouse jumps to it momentarily, then the RDP client retransmits the old mouse location (forcing the gain to about -9db), and then the popup closes. I guess the RDP client is sending the old mouse position on mouse-release.

So it’s not possible to select the gain slider via mouse without corrupting it. Tabbing to it seems to be the only safe way.

Ah, ok I see what you mean.

I’ll see if I can put in a work around when running under RDP.

Is it just the sliders that cause problems?


Yes, so far I’ve only seen problems with sliders (gain and tempo sliders). I don’t have a touch screen, but I wonder how those react to mouse-jumps too. Maybe they’re similarly affected.

If mouse-click over RDP could perform the select-and-press-enter behavior you showed me, I think that would solve it (and hopefully not be much work to implement, since it’s an existing UI behavior). If RDP isn’t detectable programmatically, maybe it could be a config option?


Hi Kevin,

I’ve just put build 4190 with tweaks for running under RDP. Clicking it should just show the popup, you can then drag as required and click outside (or escape key) to close.



Works beautifully! Thank you, Brad!