Disable keylock when scratching with scratch2_enable.

[mixxxbot]

Reported by: rryan
Date: 2013-04-29T22:57:52Z
Status: Fix Released
Importance: Low
Launchpad Issue: lp1174578
Tags: keylock, scratching
Attachments: controller_keylock.patch

---

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.

[mixxxbot]

Commented by: Pegasus-RPG
Date: 2013-04-30T05:56:40Z

---

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?

[mixxxbot]

Commented by: rryan
Date: 2013-04-30T13:16:55Z

---

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

[mixxxbot]

Commented by: Pegasus-RPG
Date: 2013-04-30T15:43:54Z

---

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.

[mixxxbot]

Commented by: ywwg
Date: 2013-04-30T15:53:49Z

---

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.

[mixxxbot]

Commented by: rryan
Date: 2013-04-30T19:51:31Z
Attachments: controller_keylock.patch

[mixxxbot]

Commented by: rryan
Date: 2013-04-30T23:12:02Z

---

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. :)

[mixxxbot]

Commented by: Pegasus-RPG
Date: 2013-05-01T05:27:56Z

---

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.

[mixxxbot]

Commented by: Pegasus-RPG
Date: 2013-05-01T06:18:40Z

---

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?

[mixxxbot]

Commented by: rryan
Date: 2013-05-01T13:35:08Z

---

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 :).

[mixxxbot]

Commented by: thomsen
Date: 2013-05-01T20:05:24Z

---

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?

[mixxxbot]

Commented by: rryan
Date: 2014-03-15T12:58:37Z

---

Releasing this bug to someone else.

[mixxxbot]

Commented by: rryan
Date: 2014-03-18T20:24:18Z

---

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

[mixxxbot]

Commented by: rryan
Date: 2014-03-18T20:25:31Z

---

(not sure why I marked this Wishlist)

[mixxxbot]

Commented by: ywwg
Date: 2014-03-18T21:05:22Z

---

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.

[mixxxbot]

Commented by: rryan
Date: 2014-03-18T21:34:35Z

---

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).

[mixxxbot]

Commented by: thomsen
Date: 2014-03-18T22:07:16Z

---

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!

[mixxxbot]

Commented by: ywwg
Date: 2014-03-19T17:14:48Z

---

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?

[mixxxbot]

Commented by: rryan
Date: 2014-11-23T07:01:04Z

---

I believe this was finally fixed by Owen in this PR:
#200

Right Owen?

[mixxxbot]

Issue closed with status Fix Released.