Customizable soft-takeover threshold.

[RJ Skerry-Ryan]

<christian_h> hi everbody! trying to configure mixxx for a reloop
              mixage. right now i'm fighting with soft-takeover. either the
              controller or mixxx are doing crappy stuff. the take over jumps
              in much too early and after that no fast movements of the faders
              and knobs are possible. any idea how to solve this? [16:27]

<christian_h> rryan: added a softtrack via js. if a use a difference of 10, I
              can move the knobs smooth. but fast movements are still
              impossible.

This seems to not be a one-size-fits-all sort of thing. The current threshold is 3/128. It should be customizable, maybe on a per-control basis.

[Sean M. Pappalardo (pegasus-renegadetech)]

Some Reloop controllers (I've tested the Terminal Mix series) have soft-takeover in firmware, and I've found that it doesn't work nearly as well as our software one, especially when moving knobs quickly. On top of that, enabling it in software too would only make the situation worse. So unless there's a way to disable it in firmware, you're kind of stuck with that one. We should contact Reloop about this.

So while more adjust-ability is good, I'm not sure adding this bug's request would actually help much since the OP's problems likely stem from an inferior firmware implementation which we can't do anything about in software. In addition, if you're looking to do it on a per-control basis, that means using a(nother) QList or QHash, and soft-takeover is calculated in two different places depending on whether the control is scripted or not. We should take a public poll and see how many controllers would actually benefit.

[Musikpirat (w-launchpad)]

Hi there, christian_h speaking. :)

I'd suggest a different approach: More intelligent takeover. As soon as the controller state of a control and Mixxx's state of the same control are close to each other, the takeover is no longer needed, so it can be safely disabled. This way you can move the controllers with your desired speed.

I implemented this as a midi script and it works exactly the way I thought a soft takeover should work.

[RJ Skerry-Ryan (rryan)]

Sean - how does that reconcile with the fact that Christian did his own
soft takeover in script and didn't have any issues?
On Apr 28, 2013 2:20 AM, "Sean M. Pappalardo" <email address hidden>
wrote:

> Some Reloop controllers (I've tested the Terminal Mix series) have soft-
> takeover in firmware, and I've found that it doesn't work nearly as well
> as our software one, especially when moving knobs quickly. On top of
> that, enabling it in software too would only make the situation worse.
> So unless there's a way to disable it in firmware, you're kind of stuck
> with that one. We should contact Reloop about this.
>
> So while more adjust-ability is good, I'm not sure adding this bug's
> request would actually help much since the OP's problems likely stem
> from an inferior firmware implementation which we can't do anything
> about in software. In addition, if you're looking to do it on a per-
> control basis, that means using a(nother) QList or QHash, and soft-
> takeover is calculated in two different places depending on whether the
> control is scripted or not. We should take a public poll and see how
> many controllers would actually benefit.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1173796
>
> Title:
> Customizable soft-takeover threshold.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1173796/+subscriptions
>

[RJ Skerry-Ryan (rryan)]

RE implementation complexity I was looking over the ST code and I think it
could be reworked to support this. We should decide if we want it and not
worry about implementation.

On Apr 28, 2013 2:20 AM, "Sean M. Pappalardo" <email address hidden>
wrote:
>
> Some Reloop controllers (I've tested the Terminal Mix series) have soft-
> takeover in firmware, and I've found that it doesn't work nearly as well
> as our software one, especially when moving knobs quickly. On top of
> that, enabling it in software too would only make the situation worse.
> So unless there's a way to disable it in firmware, you're kind of stuck
> with that one. We should contact Reloop about this.
>
> So while more adjust-ability is good, I'm not sure adding this bug's
> request would actually help much since the OP's problems likely stem
> from an inferior firmware implementation which we can't do anything
> about in software. In addition, if you're looking to do it on a per-
> control basis, that means using a(nother) QList or QHash, and soft-
> takeover is calculated in two different places depending on whether the
> control is scripted or not. We should take a public poll and see how
> many controllers would actually benefit.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1173796
>
> Title:
> Customizable soft-takeover threshold.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1173796/+subscriptions

[Sean M. Pappalardo (pegasus-renegadetech)]

"As soon as the controller state of a control and Mixxx's state of the same control are close to each other, the takeover is no longer needed, so it can be safely disabled. This way you can move the controllers with your desired speed."

That's not entirely true: if you then move that control on-screen or from a different MIDI controller, then move it from the first controller again, you'll have a jump in the value if you've disabled ST. This is the problem that ST was designed to prevent. Basically, there's a dichotomy between moving controls quickly (and/or controllers that don't report new values fast enough) and avoiding sudden value jumps, since rapidly moving a control sends values that are far apart, which is by definition a large value jump.

RJ: I think the ideal solution would be to keep track of which source last changed the value of any MixxxControl. If the new value is coming from the same source, then use it regardless. If not, apply the ST logic. I'm afraid that this would have to be provisioned in Control 2.0 though since there's no way to store such stuff with the current ControlObject system. And the source tracking would need to be down to the particular instance: e.g. which controller, not just "MIDI script"

[Musikpirat (w-launchpad)]

Forget to mention a step: If a control is changed in Mixxx, my soft-takeover is reenabled.

[Owen Williams (ywwg)]

Can you post your changes? this sounds very useful

[Swiftb0y (swiftb0y)]

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