If Quantization is enabled, Hotcues start from a offset position on a playing deck

[mixxxbot]

Reported by: esbrandt
Date: 2014-01-04T08:27:30Z
Status: Fix Released
Importance: Undecided
Launchpad Issue: lp1265986
Tags: cue

---

Mixxx 1.12.0-alpha-pre git master r3881

• Set rate slider to -50% ( for better visibility of the bug)
• Disable Quantization
• Set Hotcue 1 somewhere in the track, but between two bars
• Play track
• Enable Quantization
• Press Hotcue 1 button

Expected behavior:

• Hotcue starts from the position it was set to

Actual behavior:

• Hotcue starts from the position set + a positive offset.

Interestingly, this is only if the track is played back.
If you press Hotcue 1 on a stopped deck with quantization enabled, the hotcue's playpack position is correct.

[mixxxbot]

Commented by: daschuer
Date: 2014-01-04T12:21:43Z

---

For me, it sound like that this is a feature.
The track is still on a continuous beat grid, right? If yes, I think it is a desired behavior.

[mixxxbot]

Commented by: esbrandt
Date: 2014-01-04T12:45:05Z

---

Stupid me, its a feature :-)

In v1.11, it works different. As described in #⁠1 "Expected behavior"

[mixxxbot]

Commented by: rryan
Date: 2014-01-04T18:37:52Z

---

I'm not sure what the right behavior is here. I feel odd about quantizing a hotcue after it has been placed. Previously we only quantized it if the hotcue was placed when quantize was enabled.

[mixxxbot]

Commented by: ywwg
Date: 2014-01-05T00:36:42Z

---

This is bumping up against "all seeks quantize to beats". Since the enginebuffer doesn't know that a hotcue is a special kind of seek, there's no way for it to know not to quantize. And if we move the seek code back out of the engine process call, we again get off-by-one-buffer seeks.

I'd like to rewrite how seeking is done because we have a need for different types of seeks with different quantization patterns... The ideal situation would be a messaging system that can express all of these things:

• seek to exactly this location no matter what.
• seek to this location and then quantize to the beat
• do a seek such that the phase of this deck matches master sync

I could probably just change m_bSeekQueued, which is actually an int, to store an enum value that could mean one of those things. Then when the engine buffer processes the call it can take the appropriate action. The cuecontrol can ask for exact seeking, whereas the synccontrol can ask for a phase sync.

(I wonder what happens if master sync is on and you push a non-aligned hotcue? )

It's really late in the game for 1.12 to be rewriting this, of course... is it worth it?

[mixxxbot]

Commented by: ywwg
Date: 2014-01-05T01:24:10Z

---

boom: https://github.com/mixxxdj/mixxx/pull/144/files

[mixxxbot]

Commented by: ywwg
Date: 2014-01-05T03:55:16Z

---

hotcues are now exempt from Quantize. If you select a hotcue with mastersync active, it will happily unsync your tracks.

[mixxxbot]

Commented by: daschuer
Date: 2014-01-05T08:36:36Z

---

Hi Owen, thank you for working on that.

What are the use cases for the different seek hot cue seek behaviors?
Does this patch also effect THE Cue?

For me we have two use cases:

1. Label position of tracks to easily start them at different points
2. Manually Loops: rewind a track to a hot cue while playing to play parts again
3. forward a track to a hot cue while playing to skip parts
4. Drum machine

for 1 + 2 + 3 the original behavior seems to me the desired one. Only 4 needs the patch.

What is the work flow now for 1 + 2 + 3 if you don't want to get out of sync if you miss the right moment for the button press?

Before the patch, it was possible to switch between "start at hotcue (possible out of sync)" and "start synced" by the quantization button. Now this "feature is gone". What is the alternative work flow?

Is there a way to auto detect the use case?

[mixxxbot]

Commented by: ywwg
Date: 2014-01-05T14:40:46Z

---

hm, you may be right that we lost important functionality. I think the patch in general is robust, the real problem is that our hot cue system needs meta data. so maybe for now we'll keep the hot cues in regular seek mode, not seek exact mode. eventually we can have special hotcues that demand exact seeking.

[mixxxbot]

Commented by: ywwg
Date: 2014-01-05T16:29:03Z

---

OK I changed most of the hotcue seeks to be seekAbs, not seekExact. But for the goto-and-stop seeks, I made those exact since it would be weird for the deck to sync phase in that case. This will need testing by people who actually use hotcues! (I just use them as visual markers, I never actually seek to them).

[mixxxbot]

Issue closed with status Fix Released.