Soft-takeover not working on dynamic physical controls

[mixxxbot]

Reported by: Pegasus-RPG Date: 2015-11-28T17:12:23Z Status: Triaged Importance: Medium Launchpad Issue: lp1520798 Tags: controllers

---

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);

[mixxxbot]

Commented by: daschuer Date: 2015-11-28T22:34:14Z

---

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.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-11-28T23:23:04Z

---

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

[mixxxbot]

Commented by: daschuer Date: 2015-11-29T00:43:41Z

---

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.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-11-29T01:49:04Z

---

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?

[mixxxbot]

Commented by: daschuer Date: 2015-11-29T10:34:26Z

---

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

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-11-29T16:31:29Z

---

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.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-11-30T08:38:02Z

---

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

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-11-30T08:39:42Z

---

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.)

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-12-10T14:11:34Z

---

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.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-12-10T21:30:57Z

---

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

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-12-10T23:55:33Z

---

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.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2016-01-07T16:17:02Z

---

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.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2016-01-07T16:50:47Z

---

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

[mixxxbot]

Commented by: daschuer Date: 2016-01-07T21:02:21Z

---

> 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?

[mixxxbot]

Commented by: Pegasus-RPG Date: 2016-01-07T21:23:35Z

---

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.)

[mixxxbot]

Commented by: daschuer Date: 2016-01-07T22:02:32Z

---

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

[mixxxbot]

Commented by: rryan Date: 2018-09-20T17:57:48Z

---

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

[mixxxbot]

Commented by: kousu Date: 2021-09-09T07:31:10Z

---

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.

[mixxxbot]

Commented by: kousu Date: 2021-09-09T07:34:36Z

---

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)