[BUG] Undesirable behavior of VFO A when controlled via Midi

[Latidude0815]

Describe the bug

If I turn the VFO wheel a little faster, the frequency change of the VFO movement runs longer than I turn the VFO wheel. Just as if the commands were running through a slow bucket brigade memory.
Since I only notice the behavior when controlling VFO A, but not with VFO B, I suspect a BUG

To Reproduce
Steps to reproduce the behaviour:

1. Control Thetis via the Midi interface
2. Quickly rotate the VFO wheel. You can also turn the VFO wheel several times quickly half a turn to the left and to the right.
3. With VFO B, the frequency follows exactly the movements of the VFO wheel.
4. With VFO A, the frequency continues to change for a moment, even if the VFO wheel is no longer moved.

Expected behaviour
The frequency changes not only for VFO B but also for VFO A, analogous to the turning of the VFO wheel.

Screenshots
Under this link you will find a small video:
https://www.dropbox.com/scl/fi/utmox1yiwzz64l6c1clji/Thetis-Vfo-demo.mp4?rlkey=lccwdfpzpsikbns03g6a293de&dl=0

Desktop (please complete the following information):

• Win 11 Pro, AMD Ryzen 7 7840HS
• Thetis v2.10.3.8 x64

Additional context
I use a self-made midi controller built with a Teensy. It should behave like a usual midi controller :-) .
To change the frequency, I use the same VFO wheel for VFO A and B. Switching between >>Change Freq Vfo A<< and >>Change Freq Vfo B<< is done via >>Swap Vfo Wheels<<.

[ramdor]

The issue is caused by the midi events stacking up in the midi buffers, at a faster rate than thetis can deal with them. Unfortunately all midi actions under the hood talk/control thetis via cat, which is running on the same thread as the UI.

I expect filter display is the main culprit in your setup as it is doing quite a bit of work to the wdsp analysers to track the vfo changing (adjusting pan in the mini analyser). That extra work is enough to get this issue to show itself. You are not showing a filter view for vfob so not seeing it happen.

I have just tested this and if I load up my system with hundreds of meter/gadgets and no filter display then I can get it to happen on midi wheel events, so is just not limited to filter display, and the same issue occurs with rx2 enabled and using vfoB.

Unfortunately it will require some rework of Midi, to rate limit the messages for wheels/sliders/knobs. Lower spec systems will see this happen sooner.

[Latidude0815]

Hi Ritchie, thanks for your quick reply. I hadn't expected that at all. I'm just interested in reporting a possible bug.

In fact, the small filter display affects the behavior.
Following your hint, I have activated the small filter display for RX2. Then I observe a delay with VFO B as well.
Conversely, I deactivated the small filter for RX 1 and the delay on the VFO A was reduced.
Since several other containers for RX1 are running in my setting, a noticeable delay remains.

With a more powerful PC, the effect is of course smaller. But your approach of limiting the messages for wheels/controllers at some point is certainly the better one. I'm looking forward to it coming one day. It is certainly not a priority.

This small bug does not cast a shadow on the great work that you and of course the rest of the people involved at Thetis have done.

Even at the risk of it being too much for some, many thanks for your tireless work!

[ramdor]

Yes—panning the analyzer’s spectrum display in real time to track frequency is very CPU‑intensive. The same goes for zooming in and using the pan slider on the main UI: once you start moving things, updates will pause in the spectrum whilst it is reprocessing.

To alleviate this, I’ve throttled the filter‑view refresh rate to no faster than about 4 frames per second while frequencies are changing. I’ve also fully optimised the VFO CAT routines and added extra checks in the meter handlers so that they skip all processing if the frequency, band or mode hasn’t actually changed. Those tweaks should cut down on unnecessary work.

That ought to make things feel smoother. As for the MIDI rate‑limit, it’s a bit restrictive—there really needs to be a lower bound to provide realistic feedback. I’ll revisit that later, but not in the immediate future.