Comment 19 for bug 1531876

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