Hot cues set while playing on-the-fly are late

[Sean M. Pappalardo]

When setting hot cues on-the-fly from a MIDI controller, the cue point is actually recorded a bit later than when the button was pressed, even at 1ms latency, making the feature difficult to use. In 1.7.x, the SCS.3d script did hot cuing internally, recording the current value of visual_playposition and simply setting playposition on recall. It worked very well and had near-instant response at 1ms latency. Can anything be done to decrease the lag time between button press and cue point recording in 1.8? (Maybe even measuring the lag then compensating for it?)

Again, cue recall is fine. It's just that the cue point marker is set late (shows up after the desired point on the waveform as well.)

Tested on Windows x64 with Stanton SCS.3d MIDI controller.

[RJ Skerry-Ryan (rryan)]

Sean, can you reproduce this with the GUI or is it MIDI specific? At 5ms latency both cues and hotcues work perfectly for me via the GUI. When I set a hotcue on what I perceive to be a beat, the marker is positioned on the onset and jumping to the marker starts the sound from where I thought I was marking the hotcue.

Thanks,
RJ

[Sean M. Pappalardo (pegasus-renegadetech)]

It happens with the GUI hot cue buttons as well. 32- and 64-bit versions of Mixxx.

[RJ Skerry-Ryan (rryan)]

Can you try this patch?

[Sean M. Pappalardo (pegasus-renegadetech)]

Patch tests good for me. There's still a slight lag at 42ms latency, but 21 and below is fine. So for completeness you might want to add a small negative offset (relative to the latency) for latencies higher than 21.

[RJ Skerry-Ryan (rryan)]

OK, all the MIDI commands are latency-dependent so instead of adding hacks for this one in general, I'd rather fix it so the control system doesn't have this limitation. Committing to 1.8.x branch so fix will be in 1.8.1

[Swiftb0y (swiftb0y)]

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