Midi lights not set correctly when a setting is changed mid-processing by Mixxx engine
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Fix Released
|
Low
|
Unassigned |
Bug Description
Sometimes we use logic like this:
slot_mycontrolo
if (badconditions) {
mycontrolob
}
}
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:
sendshortmessag
sendshortmessag
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
Changed in mixxx: | |
importance: | Undecided → Low |
milestone: | none → 1.12.0 |
Changed in mixxx: | |
status: | Fix Committed → Fix Released |
Possible fix: have the output handler check to make sure the Changed value it received is up to date.