Midi lights not set correctly when a setting is changed mid-processing by Mixxx engine

[Owen Williams]

Sometimes we use logic like this:

slot_mycontrolobject_GotAChange() {
  if (badconditions) {
    mycontrolobject->set(revertchange);
  }
}

we do this for things like resetting the rate slider, or ignoring when
the user pushes the play button when no track is loaded, etc.

This used to work fine, but I'm having problems now that the message
queue is different. The midi lights get out of sync with the control
object. So if the above code happens, what I get out of midi is:

sendshortmessage(revertedchange);
sendshortmessage(originalincorrectvalue);

Based on stack traces I think this is because the call to ->set occurred
instantly, before the midi message corresponding to the original slot
call has been processed. The revert goes through, then the original call
continues and the midi controller is updated with the out-of-date value.

I have tried making the midi connection queued, but that didn't work.
What did end up working was firing a singleshot qtimer that resends out
the correct values on the next pass. That doesn't feel awesome and
looks hacky. Is there some other way of fixing this?

Steps to Reproduce:
1. connect a controller with lights
2. start mixxx
3. do not load a track in deck 1
4. push the play button

correct behavior:
* the play light on the controller does not illuminate

trunk behavior:
* it does

[Owen Williams (ywwg)]

Possible fix: have the output handler check to make sure the Changed value it received is up to date.

[jus (jus)]

Is this still an issue?

[Owen Williams (ywwg)]

We've added a patch so this is fixed.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7068