Waveform scratch: track is always stopt before mouse speed is adopted

Hm, this is intentional since if you click the waveform and don't move it should stop.

But It stops before it knows if the mouse moves. It should not stop if the mouse initial moves with waveform speed.

The patch from Bug #1086999 solves the problem.

I will prepare a separate patch for this issue.

The patch from Bug #1086999 solves the problem again!

This is the reply to Bug #1086999 #26 from Jus:

> * Is the delay intentional that occurs when you hold the waveform? It is
> noticeable and feels a little strange. The higher the latency, the more
> significant the effect, nearly brake-like at high latency. If you touch a vinyl,
> it holds immediately. Thats what i would expect from our mouse scratch too.

With mouse scratch we have the problem, that the mouse updates are processed in non equal times with an undefined delay and we cannot distinguish if the mouse is stopped or the mouse update is delayed.

The mouse issues are handled by a p controller which adds a delay of ~50 ms to the mouse scratch in slatted state.

This is not like the finger on the vinyl as the ideal case would be. Mouse scratching id more like scratching with a ball pen spring :-)

For starting mouse scratch, we have two use cases:
* Stopping the track
* start scratching

Have you tested scratch start? My test was moving the track with a rate of one by mouse.

The patch changes the waveform start on a playing deck with to a settled controller with the current rate.
This way it is possible to change the track rate while scratching without always starting at zero which produces a hearable pause . (The issue of this bug)
The drawback of this approach is break effect you have noticed if you want to stop the track. (Like stopping with a ball pen spring)

I like the patch because it introduces the same behavior for the whole mouse scratch process. But I understand the objections when testing track stopping.

Is stopping the track via waveform scratch a valid use case when DJing? (We have the pause button in any case). For me, starting scratching is the main use case which should work fine first.

If you not agree, we may not fix this bug, or delay the scratch start and stop until we can decide if the mouse is stopped or moving (after ~50 ms)

the patch from Bug #1117806 includes a solution for this bug with
stop detection.
@Jus, hope you will like it now ;-)

Committed to lp:mixxx 1.11 revision 3776.

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