Soft takeover only works once.

[Craig]

Running Mixxx 2.0.0 (build 1.12 r5772) on Windows 10

Discovered while attempting to create a mapping for the Behringer CMD Studio 4a.

Example of XML:

            <control>
                <group>[Channel1]</group>
                <key>volume</key>
                <status>0xB0</status>
                <midino>0x70</midino>
                <options>
                    <soft-takeover/>
                </options>
            </control>

The first time the "un-synced" controller approaches the level in Mixxx soft-takeover works. If (when!) the controller becomes "un-synced" again (e.g. after a deck switch on the CMD Studio 4a) soft takeover no longer works for that controller.

The Wiki suggests the soft takeover functions as follows:

     "prevents the physical control from affecting Mixxx until it's close to the on-screen control's position."
(from http://mixxx.org/wiki/doku.php/midi_controller_mapping_file_format)

Which seems perfectly sensible.
However I've read other bug reports that suggests there is a more complex algorithm in place (or that this function only works if you script the controller in a particular way). However, I suspect that a simple (dumb) soft-takeover function (as described inn the Wiki) is what is required by the vast majority of users (at least I need it here! :-)) so even if there is a more complex algorithm in place at the moment I think it would be useful to have the "dumb" version available (usable with the XML definition alone as the Wiki suggests).

If this really is a functionality problem (and not just a bug), and if changing the functionality would cause backwards-compatibility issues, then perhaps an alternative "dumb" option could be added (e.g. <soft-takeover2/>)

[Owen Williams (ywwg)]

Deck switches require a special API call to "reset" the state of the soft takeover. Configs for Vestax VCI400 and Traktor Kontrol S4 currently make this call so that pattern could be copied to this controller.

(A possible long term solution would be factoring out deck switch behavior into a utility library)

[Daniel Schürmann (daschuer)]

Hi Craig,

does you controller emit a midi message when switching the decks?
This can probably be used to "reset" all <soft-takeover2/> controls.

[Craig (craigeastonuk)]

In response to Daniel, as far as I know, no, the CMD Studio 4a does not emit a "deck switch" message. Again (as far as I know) you have to assume that all 4 "virtual" decks are completely independent and that the any controller can therefore become "unsynchronised" at any time.

In response to Owen (and more generally), yes I have read other (bug) reports about this issue and while I don't yet fully understand them all, the fundamental issue seems to be that there is a (notionally) more sophisticated algorithm for soft-takeover in Mixxx than the Wiki suggests (that seems to require some scripting). I'm sure that there are a number of controllers that might require this more sophisticated algorithm, but my (admittedly naive) experience so far is that the simple (dumb) soft take-over functionality (possibly with a "tweak-able" sensitivity setting) described in the Wiki is *probably* what is required most of the time, (it's certainly what I need for this deck right now).

I'm not advocating that the current algorithm be removed or altered (I suspect many controller mappings now make use of it), but I don't think this more sophisticated algorithm should be implemented at the expense of the "dumb" algorithm that will probably work for the the majority of cases, hence my suggestion that the "dumb" option be (re) implemented with a modified XML tag such as <soft-takeover2/>

As some background to this report, I'm currently trying to implement a mapping for the Behringer CMD Studio 4a. I know there is a very impressive (partial) mapping for this deck in the forum already (created back in 2013), but this is *entirely* scripted (i.e. *all* buttons and controls are implemented in script) which seems an overkill (and also makes the mapping very difficult for other users to customise). Plus there is still no "official" support in Mixxx for this deck, so I though I would try to implement a mapping using XML only (as far as is possible), and only resort to scripting where absolutely necessary.

[Craig (craigeastonuk)]

This report was marked as a duplicate of bug #1531876 but I have removed this link as I don't want this issue to be confused with (possibly related) scripting issues. As mentioned above, my goal is to create a mapping with the minimum of scripting for both simplicity and to allow others (who may not be familiar with scripting) to be able to easily modify the mapping.

The ideal scenario would be that I can just mark the XML control as a "soft-takeover" control and have it function as is currently described in the Wiki (again possibly with an adjustable sensitivity so that the function is as generally useful as possible).

[Owen Williams (ywwg)]

changing priority to medium -- this is not a problem with a core feature of the application that will affect many users (see http://mixxx.org/wiki/doku.php/launchpad_bugs)

[Daniel Schürmann (daschuer)]

Thank you for the info. It looks like we have nothing more than a changing Midi value to detect a out of sync situation.

In old two deck times, the only reason for a midi control to being out of sync was when user touches the control by the GUI.
This could be easily distinguish by the source of the control change GUI vs Midi.

Now with n-decks we have the demand to switch midi controls between two or more Mixxx control objects.

Some times ago we had an algorithm that only uses the distance to the previous value as indicator. This was very unreliable since there is a fuzzy distance that can be a fast Midi control transition or a first midi message after the Midi control was switched back to the Mixxx control object. Because of this we had bug reports that a Midi control looses its control object or on other hand the control jumps because of snapping in to early.
Going back to such a solution would be a band-aid here, but will suffer again these issues.

So we need to do something more intelligent:
We need to tell Mixxx that [Channel1],volume and [Channel3],volume are controlled by the same midi control.
This way it can reset soft takeover, once it received Midi messages from any other control in the group.

What could be a good maintainable format for this?

[Daniel Schürmann (daschuer)]

After diving though the Mixxx code, it looks like a notation like this is almost natural:

            <control>
                <group>[Channel1]</group>
                <key>volume</key>
                <status>0xB0</status>
                <midino>0x70</midino>
                <options>
                    <soft-takeover/>
                </options>
               <softTakeoverIgnoreNextValue>
                    <group>[Channel2]</group>
                    <key>volume</key>
               </softTakeoverIgnoreNextValue>
               <softTakeoverIgnoreNextValue>
                    <group>[Channel3]</group>
                    <key>volume</key>
               </softTakeoverIgnoreNextValue>
            </control>

Is it maintainable?

[Daniel Schürmann (daschuer)]

This means, if 0xB070 is received, the value is passed to [Channel1],volume, at the same time are the softtakover state machines of [Channel2],volume and [Channel3],volume reset. Their values will be ignored until they are snapped in again.

[Craig (craigeastonuk)]

To respond to your earlier question about the deck-change message, (and for the sake of completeness), it seem this deck does indeed send a MIDI message when the deck changes (the poor Behringer documentation does not mention this!) I discovered this after putting Mixxx into controllerDebug mode. However, I still think it should be possible to accomplish this without scripting.

Your idea of telling Mixxx about duplexed controllers sounds like an interesting solution, however I still think the old "dumb" behaviour should be made available, (i.e. that the new more sophisticated behaviour should not be implemented at the expense of the more general dumb behaviour as this will *probably* be sufficient inn the majority of situations). Plus I guess there is also the possibility that a controller could become unsynchronised for other reasons than duplexed controls (e.g. when a deck is first powered up perhaps?)

Also, since the old dumb behaviour used to be the norm, I assume it would be relatively easy to re-implement (again perhaps with an adjustable sensitivity and using an alternate XML tag as suggested above so a not to break existing behaviour/controller-mappings).

[Sean M. Pappalardo (pegasus-renegadetech)]

Craig, we understand what you're asking for. The problem is that (with the current algorithm,) we have to choose between allowing soft-takeover to work as you describe (where physical controls can be dynamically remapped either by script or in hardware as in the CMD Studio 4a) and allowing controls protected by soft-takeover to be moved very quickly and not lose sync. (For the record, many other controllers that change decks send different MIDI messages for the alternate deck, avoiding this conundrum.)

Also, the same code is used for soft-takeover functionality regardless of whether it's set in XML or script. This is in fact a duplicate so please vote for that bug and let's continue discussion there.

[Daniel Schürmann (daschuer)]

The takeover condition when a deck is first powered up is already covered by the current soft-takeover implementation.

I understand your proposal.
But since it already turns out that such a solution is unreliable. It would be nice if we find a rock-solid alternative. So any ideas are welcome. Maybe there is a way to make the "dump" algorithm smart.

Are there any other situation where the proposal of #7 will fail?
I would also like to know if the is something else what you dislike.
Will the additional maintenance be doable?

By the way: The extended notation from above #7 will also allow to catch the deck switch message.

            <control>
                <status>Switch</status>
                <midino>Message</midino>
               <softTakeoverIgnoreNextValue>
                    <group>[Channel2]</group>
                    <key>volume</key>
               </softTakeoverIgnoreNextValue>
               <softTakeoverIgnoreNextValue>
                    <group>[Channel3]</group>
                    <key>volume</key>
               </softTakeoverIgnoreNextValue>
            </control>

So you can build a big block of all controls of one deck.

[Sean M. Pappalardo (pegasus-renegadetech)]

Daniel, that seems more complicated that it needs to be.
We just need to create a CO that resets soft-takeover for the given control, then the XML needs only map that message to that CO like any other Mixxx control (and it would work in the GUI mapper.) e.g.
            <control>
                <group>[Channel1]</group>
                <key>st_ignore_next</key>
                <status>0x90</status>
                <midino>0x7F</midino>
            </control>

[Sean M. Pappalardo (pegasus-renegadetech)]

Sorry, I mean the deck change message.

[Sean M. Pappalardo (pegasus-renegadetech)]

And I meant "the given group". (Stupid LP not letting me edit comments...)
So my example would tell Mixxx to call IgnoreNext on all controls mapped to COs with a group of "[Channel1]" (that have the soft-takeover option set of course.)

[RJ Skerry-Ryan (rryan)]

@Sean -- the [Channel1],st_ignore_next CO would ignore-next on all channel1 COs? Seems a bit extreme.

[Sean M. Pappalardo (pegasus-renegadetech)]

All that had Soft-takeover set via XML option.

[RJ Skerry-Ryan (rryan)]

Hi Chris -- I think it'd be useful if you could share some MIDI dumps using --controllerDebug and post your preset XML / js (if any).

thanks!

[RJ Skerry-Ryan (rryan)]

For the MIDI dump, perhaps you could annotate it with what's going on like:

1) Move Ch1 volume knob (sync'd, Mixxx is responding)
2) deck switch
3) Move ch3 volume knob (getting CH1 out of sync)
4) deck switch
5) Move ch1 volume knob -- not ignored by soft takeover when it should have been
6) ch1 volume knob approaches on-screen ch1 volume knob position -- not re-sync'd by soft takeover as it should have been

[Craig (craigeastonuk)]

To respond to Sean's comment:
  >>Craig, we understand what you're asking for. The problem is that (with the current algorithm,) we have to choose between
  >> allowing soft-takeover to work as you describe (where physical controls can be dynamically remapped either by script or in
  >> hardware as in the CMD Studio 4a) and allowing controls protected by soft-takeover to be moved very quickly and not lose
  >> sync.

I'm a noob here, (and perhaps I'm playing devils advocate in somewhat), but may I as why?

What I'm proposing is a re-implementation of the old "dumb" behaviour under a new tag so as not to break existing behaviour i.e. developers don't have to make this choice, leave it to the users! :-), e.g.

switch(option)
{
    case "<soft-takeover/>":
        ...
             implement existing behaviour.
        ...
        break;
    case "<soft-takeover2/>":
        ...
             implement old "dumb" behaviour.
        ...
        break;
}

I know that the old behaviour may not work in all cases, (e.g. fast changing controllers), but so what? A user would only use <soft-takeover2> (or whatever) in situations where it is suitable (and I suspect that this behaviour is *probably* sufficient in the majority of cases, (e.g. volume faders, effects parameter knobs, etc.)

The "duplexed controller" idea (e.g. defining groups of parameters controlled by the same physical controller, or by whatever other means) seems perfectly sensible (I suspect it would also work fine for my situation so I certainly don't want to argue against it! :-) ), but perhaps it's more complicated than needed? (at least for my situation). Also, I think a "one algorithm fits all" approach is always going to be destined to fail here as there are obviously a number of different usage cases for soft-takeover functionality, e.g. re-syncing when the GUI has been altered, re-syncing when a "virtual" deck has been switched, re-syncing a fast controller (cross-faders??), re-syncing because of missed MIDI messages???, ...

[Sean M. Pappalardo (pegasus-renegadetech)]

The algorithm hasn't changed much since its initial release in Mixxx v1.10. To prove it, please try loading a subset of your mapping into Mixxx v1.11 (without any of the 2.0 MixxxControls,) and see if the soft-takeover behavior is the same as in 2.0.

[Daniel Schürmann (daschuer)]

(Launchpad does not notify use when a message arrives during you file a new one, that's why we got two threads here, but lest try to round it up)

@Craig: You proposal would work if you keep you mapping private, but once it is feed to the wild, you cannot predict who will use it under which condition or DJ style. A failing solution may throw a bad light on Mixxx, so we should head for a rock solid solution.
My fist proposal is probably also not suitable because it is hard to "learn" in all aspects. Facing that probably competitors only support the "dump" algorithm. So lets work together for a suitable solution for "Mixxx".
I would be happy about a comment one #11.

@Sean: You proposal is a good step in the right direction. If I look on the 4A Midi Map: http://origin.behringer.com/assets/CMD_STUDIO_4A_MAP.pdf There are actually all [ChannelX] controls shared.
On the other hand RJ is also right, that his is probably an exceptional case.
But I like the Idea to at least allow it.

[Daniel Schürmann (daschuer)]

@Sean: Using a new control object for for ignore next seams a little bit to inflexible, since It is global and it should only affect one mapping and not an other controller that can be connected as well.

How about introduce a wild card like
               <softTakeoverIgnoreNextValue>
                    <group>[Channel2]</group>
                     <key>*</key>
               </softTakeoverIgnoreNextValue>

or:
               <softTakeoverIgnoreNextValue>
                    <group>[Channel2]</group>
                     <key></key>
               </softTakeoverIgnoreNextValue>

or:
               <softTakeoverIgnoreNextValue>
                    <group>[Channel2]</group>
               </softTakeoverIgnoreNextValue>

This would allow to reset soft-takover of a whole group and explicit from any control via a xml tag that still works as usual.

[Daniel Schürmann (daschuer)]

I un-duplicate this again even thought this is probably a duplicate, but else we will loose this worth-full discussion.

[Swiftb0y (swiftb0y)]

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