(DEBUG) S4 Mk3: compare scratch functions engine.scratch.. vs engine.setValue(group, "scratch2..")

[ronso0]

Helper to fix/debug #14000

This adds two mapping options:

• current / alternative scratching to easily compare the two methods
  curr: engine.setValue(group, "scratch2..)
  alt: engine.scratchEnable()/engine.scratchTick()
• sync scratch speed with wheel LED speed (~2x as fast as the current scratch speed)

With the alternative method scratching sounds pretty smooth at low speeds, while with the current implementation it's rather just noise (no buffer underruns, really just how wheel ticks are filtered & emitted)

Another notable difference:
with the alternative method the track is very slowly drifting backwards when doing many (40+) fast + short back & forth scratches¹.

My results:

curr: engine.setValue(group, "scratch2..):

• noisy with low scratch speeds
• no notable drift for one-direction scratches
• no notable drift for fast back'n'forth scratches¹

alt: engine.scratchEnable()/engine.scratchTick():

• smooth sound at all speeds
• no notable drift for one-direction scratches
• drifts backwards for fast back'n'forth scratches¹

Bottom line:

So, to get the best of both methods, could we use the alt. method for slow scratches?
I'll test that soon.

Or fix the filtering for the current method?
I have no clue how..

[ronso0]

edit: nonsense, speed is not used when calling the engine.scratch..functions.
Instead it seems it occured with a previous version of 2.5/main and now that I rebuilt the drift is gone 🤷‍♂️

However, this commit gives equal noise for slow backward and forward scratches with "scratch2.." controls 😆

---

I got rid of the back'n'forth scratch drift with the second commit:

if ((currentSpeed <= 0) === (speed <= 0)) {

vs.

if ((currentSpeed < 0) === (speed < 0) ||
        ((currentSpeed > 0) === (speed > 0))) {

Now scratching with the engine.scratch.. functions works great!

[acolombier]

I haven't had a chance to test yet, but I'll try to do that ASAP

[acolombier]

The new scratching experience feels very good and precision change doesn't feel as bad as I feared. I'm happy to get those two settings as part of the core mapping. 👍

Only "regression" from my perceptive is the hotcue not "cutting" the scratch anymore.
My routine being, I would scratch over, say a voice sampler and would be able to resume playing instantly by activating a hotcue. How would you feel about restoring that behaviour via an alternative setting? (e.g Stop scratch when activating hotcue and slight refactor of L2458-2470)

Another bug is, if you set a jogwheel tension higher than 0.80, the jog will speed up and never stop! I guess you might be able to adjust the range.

Let me know if you would want me to suggest patches

[ronso0]

Only "regression" from my perceptive is the hotcue not "cutting" the scratch anymore.
How would you feel about restoring that behaviour via an alternative setting? (e.g Stop scratch when activating hotcue and slight refactor of L2458-2470)

Sure, I don't plan to remove features, though I'd make the cutting opt-in.

[ronso0]

The new scratching experience feels very good and precision change doesn't feel as bad as I feared. I'm happy to get those two settings as part of the core mapping. 👍

Great to hear!
So we'd have 2 new scratching options then, both opt-in:

• make scratch speed match wheel LED speed
• seeking to hotcue stops scratching

Or where you saying the engine.scratch.. functions should be optional, too?
Given that both this and scratch2 show sticker drift and engine.scratch.. sounds much smoother at low speeds I'd actually drop scratch2.
Wdyt?