Soft-takeover not working on dynamic physical controls

[Sean M. Pappalardo]

I have a physical knob on a controller I'm working with that can be toggled between controlling [EffectRack1_EffectUnitN],mix and [EffectRack1_EffectUnitN],super1. Soft-takeover is not working on values from script whenever this knob is toggled. (It does work if left on the current mode and the on-screen control is moved.)

The handling function for this control is:
    if (deck.controlEffectParameter) {
        engine.setValue("[EffectRack1_EffectUnit"+deckNum+"]","super1",
                        script.absoluteLin(value,0,1));
    } else {
        engine.setValue("[EffectRack1_EffectUnit"+deckNum+"]","mix",
                        script.absoluteLin(value,0,1));
    }

And soft-takeover is initialized at the start of the script for these MixxxControls:
engine.softTakeover("[EffectRack1_EffectUnit1]","mix",true);
engine.softTakeover("[EffectRack1_EffectUnit1]","super1",true);
engine.softTakeover("[EffectRack1_EffectUnit2]","mix",true);
engine.softTakeover("[EffectRack1_EffectUnit2]","super1",true);

[Daniel Schürmann (daschuer)]

This happens due to the nature of soft takeover.
If you control the CO by midi, it is stored that the last value was from midi (it is in sync with midi from now) All subsequent commands from midi are treated as in sync and are not ignored. The out of sync state is only adopted if the CO is changed by a non midi write, the case that the controller knob is changed without effecting the CO is not considered.

The controller needs to tell the softtakover that is returns from "shift mode" to adopt the out of sync state.

[Sean M. Pappalardo (pegasus-renegadetech)]

But the SoftTakover class doesn't act on knobs, it acts on ControlObject value changes. See ControllerEngine::setValue()

[Daniel Schürmann (daschuer)]

Yes, right. All values set from the ControllerEngine are stored as m_prevParameter, the reference value. All other setter bypass this function, this leads to the desired out of sync state since the m_prevParameter is not changed to the new CO value.
If a knob controls an other value by shift, and comes back, the new CO and m_prevParameter are still equal and the new value is adopted.

[Sean M. Pappalardo (pegasus-renegadetech)]

Then that's a bug, hence my filing this. The SoftTakeover class is supposed to check the new value to be set against the current value of the control. If the new value is too far away (> threshold) from the current value of the CO, we ignore it. We don't even care about whatever m_prevParameter is in this case. How and why would it matter which physical control supplies the value as long as its from the same script?

[Daniel Schürmann (daschuer)]

Yes, I agree, it is a bug (or a missing feature)

Currently Soft takover is bypassed, if the control is only affected by the Controller (mapping /script)
This is correct and works very reliable in almost all cases, except yours.
So IMHO it would be a regression to move back to a simple threshold based algorithm.

To Fix this, the script needs to be able to tell the overtaker class that an absolute value control was used to do something else.
And that it has lost sync.

I have digged though the history:
The bypass and checking the side from script was introduced here:
https://github.com/mixxxdj/mixxx/commit/4b50bbb4db5ffd1340a9c3a9abf20772e35863e7

[Sean M. Pappalardo (pegasus-renegadetech)]

That's very interesting, but the current code looks very different. Let me make some adjustments and a PR you can test your controllers against.

[Sean M. Pappalardo (pegasus-renegadetech)]

https://github.com/mixxxdj/mixxx/pull/792

[Sean M. Pappalardo (pegasus-renegadetech)]

After actually reading the code, you were right, Daniel. So that PR adds the ability for scripts to tell the ST object to ignore the next value, solving the problem. (The script does indeed need to call this on every switch as you mentioned for this to work.)

[Sean M. Pappalardo (pegasus-renegadetech)]

Before we merge that PR, I've written some tests against 1.11 to verify correctness, and have run them against 2.0 and found that four cases (out of 32) fail. So there is in fact a logic problem in 2.0. Working on it.

[Sean M. Pappalardo (pegasus-renegadetech)]

And fixed, correctly this time: https://github.com/mixxxdj/mixxx/pull/804

[Sean M. Pappalardo (pegasus-renegadetech)]

Nope, scratch that. As Daniel said, fixing this bug in the SoftTakeover algorithm is mutually exclusive to being able to move controls from their current positions quickly. So back to my original PR #792.

[Sean M. Pappalardo (pegasus-renegadetech)]

https://github.com/mixxxdj/mixxx/pull/806 adds the needed re-sync function for scripts, but this still needs fixing for XML controls using the <soft-takeover/> option.

[Sean M. Pappalardo (pegasus-renegadetech)]

The next step is to discuss the ST truth-table. I'll start a post on the mailing list.

[Daniel Schürmann (daschuer)]

> https://github.com/mixxxdj/mixxx/pull/806 adds the needed re-sync function for scripts, but this still needs fixing for XML controls using the <soft-takeover/> option.

Why does it not work for xml mappings? Since they are not dynamically assigned, there should be no issue.
Or do you facing a controller with a hardware solution for remapping of a fixed scale control?

[Sean M. Pappalardo (pegasus-renegadetech)]

> Or do you facing a controller with a hardware solution for remapping of a fixed scale control?
That appears to be the case with the Behringer CMD Studio 4a as reported in bug 1531876 (which is a duplicate of this one.)

[Daniel Schürmann (daschuer)]

Bug #1531876 contains a nice description. How about to close this and track the hardware switch issue in the original bug.

[RJ Skerry-Ryan (rryan)]

Due to lack of progress, marking Triaged and clearing assignee. Feel free to revert if it is in fact still in progress :).

[Nick (kousu)]

 Hi there! I ran into this today. I am trying to use an Akai MPK Mini as a controller. It's tiny and only has 8 knobs, but it has a built-in midi channel shift feature (you hold Program + one of the four final keys to choose between channels 1, 2 3 and 4): https://www.youtube.com/watch?v=Q3PDqpCXhL4. I've made use of this to put the main mixer controls on channel 1 and the eq dials on channel 3.

soft-takeover is working well if I *don't* change channels: if I knock a Mixxx control, say the rate on deck 1, with the mouse or with a keyboard shortcut, then the physical midi knob successfully doesn't touch it until I dial it near to the value I knocked it to. However if I switch to channel 3 to control, say, the high eqs for deck 1 (which I've mapped to the same dial), then switch back to channel 1, as soon as I touch that dial again the rate will jump, ignoring soft-takeover. And vice-versa if I start by controlling the eqs with channel 3, switch to channel 1 temporarily, then switch back to channel 3: the eqs will jump as soon as I touch the dial. But it doesn't do that if I adjust the eqs with the mouse instead of the knobs.

[Nick (kousu)]

Here's my mapping, if it helps: https://gist.githubusercontent.com/kousu/9182023b2e0a9cf3b9a6fbb643f2df22/raw/3770bde623333840edee1c87ba20770240aab3c8/Akai%2520MPK%2520Mini.midi.xml

(I tried to attach it here but Launchpad is having a hard day)

[Swiftb0y (swiftb0y)]

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