Right-click pitch bend with Keylock on - error - No read ahead log entries to read from

[rob]

When scratching a track with keylock enabled, I got this error:

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

...and the audio stutters - repeating short bursts of music, like a quick record skip sort of thing. Then the scratch will work for a bit, then it'll go back to stuttering for a bit and giving that error.

This is most noticable when I'm spinning through a track fast (like, using the scratch wheel as a fast-forward), particularly when the track is not playing. it doesn't seem to happen when keylock is off. Restarting Mixxx doesn't fix it.

[Owen Williams (ywwg)]

What version of Mixxx are you using? When scratching, keylock is supposed to temporarily disable itself to prevent this stuttering effect (it's unavoidable with keylock).

We may need to add an upper bound on keylock as well if it can't handle super fast-forwards.

[rob (another-rob)]

Mixxx 1.11.0 build r3864

Right, I remember a discussion about disabling keylock while scratching, now that you mention it... When did that get implemented?

[rob (another-rob)]

This happened while testing my new Behringer CMD Studio 4a mapping - if you want to look at the scratch function, there's a "work in progress" version of the mapping posted in the controllers forum.

The only different thing I'm doing in there is sometimes setting "ramp" to false on scratch disable. Apart from that it's a pretty standard scratch function.

B4A.wheelTouch and B4A.wheelTurn are the function names

[Owen Williams (ywwg)]

it may only be in 1.11.1+ / 1.12 alpha / trunk versions. It looks like it was rolled back right before release due to a bug. I would point you to http://builds.mixxx.org/ but it seems to be down right now.

[rob (another-rob)]

No worries. I never scratch with keylock on anyhow, I just posted because I found the error while testing a new mapping, figure you guys would want to know about it.

[jus (jus)]

Raising the priority of this bug to medium because it also affects users not using controllers.

* Load track in deck 1
* Do NOT activate keylock on deck 1
* Start playback and move crossfader all over to deck1
* Load track in deck 2
* Activate keylock on deck 2
* Now right-click on deck 2 waveform and drag to make pitch adjustments
* Notice the audible dropouts in deck 1, the waveform stutter, and log entries (see subject)

[Owen Williams (ywwg)]

I can't reproduce this... is it still happening?

[jus (jus)]

Yes, still in latest master.

See video (sorry, no audio). The deck 1 dropouts are audible once keylock is enabled, and you right-click move the mouse on the deck 2. Does not matter if deck 2 is playing or not.

[Owen Williams (ywwg)]

This is not scratching, this is the pitchbend algorithm that uses the "wheel" CO to fast-forward and rewind the track.

[Owen Williams (ywwg)]

Also it's not necessary to have two decks. Just turn keylock on on one deck and right click drag is enough to trigger the bug. It looks like rubberband starts failing when the rate gets above 2.0x

[Owen Williams (ywwg)]

And I see the rubberband window size warning:
WARNING: reconfigure(): window allocation (size 8192) required in RT mode

[Owen Williams (ywwg)]

Fixed in 7dbb5166066d4fbede2eac3e166a866d96d0869b

[Swiftb0y (swiftb0y)]

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