ControlPotmeter allow out-of-bounds option

[RJ Skerry-Ryan]

In https://github.com/mixxxdj/mixxx/commit/db2f130cb32f5484ca064b83d211cb3afeeb595e
we removed the range limiting on ControlPotmeters to support master sync.

This should instead be an option to ControlPotmeter to allow out-of-bounds set()s.

[RJ Skerry-Ryan (rryan)]

Spoke with Owen and the change was only needed for the 'rate' control.

Fixed in https://github.com/mixxxdj/mixxx/commit/e21ffec0fe67e327b43fac81d3a55078112fa6f5

[Daniel Schürmann (daschuer)]

On the second thought I think this is a fix but at the wrong position.

The buttons are just an input option and should behave exactly like the slider displayed in the GUI.
In the original bug description only _up _down and _set_on is effected.
Bug #1081137

Owen's original problem was to allow out of bound values for programmatic needs, not control commands.

So the root bug was that the _up _down controls where bypassing the limit check.

Patch
https://github.com/mixxxdj/mixxx/commit/e21ffec0fe67e327b43fac81d3a55078112fa6f5
now allows to control beyond all limits for rate slider but limits all COs to be out of bound for programmatic reasons.

Possible solution:
* Remove m_bAllowOutOfBounds and check for limits in incValue() like functions. https://github.com/mixxxdj/mixxx/blob/master/src/controlpotmeter.cpp#L141 or in a common function it calls.

[Owen Williams (ywwg)]

I thought about that too, but I don't mind if someone is able to push the rate control "past the edge," even with a controller. It's a little easter egg for those tracks that are just a little too far apart. So I'd prefer to keep it as-is.

[Daniel Schürmann (daschuer)]

Are you sure that this works without an issue? There is now limit at all.

[Owen Williams (ywwg)]

You can make the track go backward if the rate goes below zero! Yeah I guess we should be able to specify hard clamps that are outside the UI range (for rate, I'd put those at 0 and like 4, maybe)

[RJ Skerry-Ryan (rryan)]

Hm, yea looks like we want rate limiting to apply on all PotmeterControls COs.

I think we still want rate limiting on almost all ControlPotmeters (except 'rate') to prevent buggy code in Mixxx (e.g. something going wrong in AutoDJ) from screwing up the engine.

[RJ Skerry-Ryan (rryan)]

On Thu, Mar 20, 2014 at 9:44 AM, RJ Ryan <email address hidden> wrote:

> Hm, yea looks like we want rate limiting to apply on all
> PotmeterControls COs.
>

Pre-coffee: range limiting

[RJ Skerry-Ryan (rryan)]

Potmeters need limiting built in by default because otherwise broken logic in Mixxx or even in a MIDI script could cause major problems (blown speakers, trainwrecks, etc.). Even programmatic access done outside the engine (e.g. in AutoDJ) should be sanity checked unless we are sure we want to allow the control to exceed its limits.

[RJ Skerry-Ryan (rryan)]

So I see this solution as: make potmeter controls obey the range limits.

[Swiftb0y (swiftb0y)]

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