Disable keylock when scratching with scratch2_enable.

[RJ Skerry-Ryan]

We disable keylock for VC scratching and mouse scratching so we ought to do it for controller scratching as well.

Some controller scripts (i.e. the Mixtrack Pro preset) already do this in script.

[Sean M. Pappalardo (pegasus-renegadetech)]

If we want to do it across the board, why not just have the scratch2_enable CO do it when it's set to 1?

[RJ Skerry-Ryan (rryan)]

Mouse scratching and vinyl control scratching don't use
scratch2_enable. If you look at RateController::calculateRate, the
scratching bool pointer argument is what EngineBuffer looks at to
decide whether to disable keylock temporarily. The patch for this is a
1-liner -- the question is whether we should do it.

On Tue, Apr 30, 2013 at 1:56 AM, Sean M. Pappalardo
<email address hidden> wrote:
> If we want to do it across the board, why not just have the
> scratch2_enable CO do it when it's set to 1?
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1174578
>
> Title:
> Disable keylock when scratching with scratch2_enable.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1174578/+subscriptions

[Sean M. Pappalardo (pegasus-renegadetech)]

I don't see why not. It doesn't make much sense to scratch with key lock on (unless someone thinks that's a cool effect,) so I'd say just go ahead.

[Owen Williams (ywwg)]

I vote yes, we should do this for controllers. The code is already in there and there is no world where scratching while pitch-locked makes sense.

[RJ Skerry-Ryan (rryan)]

I was worried about a controller getting stuck in scratch mode but Sean pointed out that if a controller gets stuck in scratch mode then it will most likely just stop so the preset and user have bigger problems in that case. :)

[Sean M. Pappalardo (pegasus-renegadetech)]

Seems to work fine for me. The only improvement I'd make is to re-enable key lock during the ramp-up after releasing scratching because right now there's an abrupt change.

[Sean M. Pappalardo (pegasus-renegadetech)]

Oh, one other use-case: moving-platter controllers that necessarily keep scratch2_enable on all the time (so the deck can accurately track the platter.) We need to provide a way for those controller scripts to make an exception to this auto-disable policy. (Currently that's just the SCS.1d and Numark NS7/V7.)

I wonder if we should move the keylock-disable action to the controllerEngine::scratchEnable so we can add a parameter for keylockDisable?

[RJ Skerry-Ryan (rryan)]

I rolled lp:mixxx r3855 -- Sean pointed out some issues that have convinced me this is not worth messing with right before a release with no beta testing :).

[Thomsen (thomsen)]

My initial description of this bug was this:

Using Mixtrack Pro, Ubuntu 13.04 x64.
Scratch and Keylock on the controller is on.
Touching the plate to "pause" playback or scratching and releasing it again causes stuttering for ½-1 second. The stutter is accompanied by a lot of:

Debug [Engine]: 0x1bf29f0 No read ahead log entries to read from. Case not currently handled.

It only happens when KeyLock is on. The problem is not seen when scratching with the mouse.

The changes in r3855 made the stuttering go away.

With that rolled back, is there any way we can modify the controller script to mimic what happens in the engine?

[RJ Skerry-Ryan (rryan)]

Releasing this bug to someone else.

[RJ Skerry-Ryan (rryan)]

Any thoughts on this for 1.12.0? This is likely quite annoying for controller users.

[RJ Skerry-Ryan (rryan)]

(not sure why I marked this Wishlist)

[Owen Williams (ywwg)]

I think this is what we do already. Enginebuffer checks for is_scratching and disables keylock if is_scratching is true. and ratecontrol checks scratch2_enable when determining whether to set is_scratching. So I'll mark it fixed. If this is actively broken for someone we can reopen.

[RJ Skerry-Ryan (rryan)]

RateControl doesn't set is_scratching for scratch2_enable, just for VC and scratch-controller (mouse scratching).

See the patch I posted above -- it makes exactly that change (scratch2_enable triggers is_scratching true).

[Thomsen (thomsen)]

This bug was reported by Ryan after a discussion on IRC. The issue that I experienced (see comment #10) seems to be fixed in trunk!

[Owen Williams (ywwg)]

So for the moving-platter controllers, how do we know if they are scratching or not? For vinyl I had to write a class that looked at the rates coming out and makes an educated guess: a certain amount of time with the rate not changing = not scratching. Do we have to write this for controllers?

[RJ Skerry-Ryan (rryan)]

I believe this was finally fixed by Owen in this PR:
https://github.com/mixxxdj/mixxx/pull/200

Right Owen?

[Swiftb0y (swiftb0y)]

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