Bug: [Qt build] Controls are escalating – unusable

[granjow]

I switched to the new Qt based fmod Studio a while ago, and I have a huge usability issue which is probably a 1-minute fix for you.

When I drag a UI element like the volume knob, an automation point, or a parameter value, the value jumps in an uncontrollable way. When I gently slide the mouse down, volume jumps from 0 to 0 … to 0 … to -∞ dB! Even when I move the mouse down by 1 cm and then up by half a cm, the values still get more negative while moving the mouse up again.

In code, what very likely happens is that once I click, you keep those coordinates as x0,y0. When I drag the mouse down, for every mouse position xm,ym you move the value by the full delta to x0,y0 instead of by the delta compared to the previous mouse position.

This is still the case in 2.03.12 (Qt 6.5.3).

I’m getting desperate when having to do anything in FMOD except for arranging clips because of this bug, please fix this

Thanks,
Simon

[Connor_FMOD]

Hi,

Thank you for bringing this to our attention.

What operating system are you on?

A workaround may be manually inputting the values:

Most values can be changed by double clicking on them, or clicking on the triangle next to some values:

[granjow]

Hi Connor,

Oh, so cool, I did not know you can double-click the values!

I’m on an Ubuntu 24.04.

Thanks for the tip, that already helps a lot!
Simon

[Connor_FMOD]

Thanks for the info.

Are you remoting into the machine or using it locally.

I find that when remoting into Linux machines interaction with the dials can be slightly aggressive. However, when using the machine locally I am able to get more gentle interaction. This could be something we could address?

[granjow]

Hi Connor,

I’m using it locally on my machine. It definitely is a bug (one which I have made too in the past, in fact), and it happened with your switch to Qt, the previous non-Qt version did not behave this way. It also happens with the AppImage version.

Simon

[Connor_FMOD]

Thanks for the info. I am still unable to reproduce the issue on my end.

I will pass on your suggestions to the development team to make sure we are calculating the differences correctly.

Is this happening on your Raspberry Pi? Once I have the disk image from our other thread I will try to reproduce the issue again.

[granjow]

Hi Connor,

this is happening on my Ubuntu 24.04, I don’t have FMOD Studio installed on the Raspberry Pi. I am on the Wayland version, but that should not make a difference, I think it is just a Qt thing.

I recorded a video to demonstrate the behaviour:

direct link (embedded version does not work for me)

[mathew]

Just a quick thought, have you tried switching the “Mouse Input Mode” in the FMOD Studio preferences?

Edit → Preferences → Interface → Mouse Input Mode

[granjow]

Thanks mathew, I changed it to Absolute Input, and it behaves as expected again!

From what I understand, the difference should be that with relative input, the mouse does not move away from the control after moving the input value (with absolute input it does, until the mouse reaches the end of the screen, then I have to move the cursor back to the value field again). But the side effect with the offset stacking is wrong, in my opinion.

Thanks,
Simon

[mathew]

Yes, that’s correct. In relative mode we hide the cursor and snap it back to the start position to give infinite movement. It certainly looks like something is misbehaving, I’ll leave it to @Connor_FMOD to track down a way to reproduce it so we can fix the real issue. Hopefully absolute mode can operate as a workaround while we investigate.

[granjow]

Thank you. Absolute mode definitely works as a workaround, actual controllability is definitely more important than infinite movement!