Allow finer granularity for the Quantize feature for more seamless loops and cues

[jus]

If the Quantize feature is activated, actions like setting loops and cues currently snap to 1 beat ( the white lines).

Current behavior
==============

(Hot)hotcues
--------------------
If the playposition is less then halve the way trough between two beats the action is performed on the PREVIOUS beat (Snap to nearest beat).

Loops
---------
For automated loops, the action is ALWAYS performed on the PREVIOUS beat, no matter how far the playpositions is between two beats (Snap to previous beat)

For manual loops, the action is performed on the PREVIOUS beats, if the playposition is less then halve the way trough between two beats (Snap to nearest beat).

Issues
=====

(Hot)cues
--------------
* Always set on a full beat, the Dj is bound to Mixxx` internal decision.

Loops
---------
* Always start on a full beat, the Dj is bound to Mixxx` internal decision.
* You can`t set manual loops smaller then 1 beat.
* Automated loops can easily get out of sync, because is the playposition more then halve the way trough two beats, the loop starts on the PREVIOUS beat. Just start 2 tracks simultaneously and hear them running in sync. Now press the 4-bar automated loop button right in the moment before the playposition is at the next beat marker. They are now out of sync, with every run of the loop a bit more.

Proposal
=======
* Allow finer granularity so that we can sync to up to 1/8 ticks in between two beats (configurable?).
* Unify behavior for (Hot)cues and automated Loops (Snap to nearest tick). We do this already for not automated (manual) loops.
* Is a new automated loops set and snapped to the to nearest coming tick ( > halve way trough 2 ticks), don`t instantly jump to the loop-In point. Normally continue playback to the loops end first, then start looping.

Maybe i missed some discussions about the decision to restrict it to 1 beat, but i think it it puts unnecessary limits to looping and that we can do better.

Thanks for listening.

[Owen Williams (ywwg)]

"Now press the 4-bar automated loop button right in the moment before the playposition is at the next beat marker. They are now out of sync, with every run of the loop a bit more."

I'm not sure what you mean by out of sync -- naturally the track that is looping will not be at the same playposition as the first track, because it is looping. Are you talking about quantize being on or off? I assume it's on since you talk about the loop starting at the previous beat. And yes, the loop will be one beat off from the phrasing, but it should still sound correct and should still remain in sync. (And you can shift the loop by one beat if necessary).

As described this sounds like a bug, but I can't reproduce it.

I know some systems will create a loop starting at the next beat and then let the playhead play into the loop -- I don't know if we can do that right now

[jus (jus)]

Sorry if i was not clear.
Basically if you have a 4/4 beat, Mixxx draws 4 beats (ticks) per bar. In my example above (with QUANTIZE enabled), you`ll will only be able to set hotcues and start loops to/from 4 positions per bar:
Tick 1.4
Tick 2.4
Tick 3.4
Tick 4.4

If you have a good timing , and try to set a quantized 4/4 loop on a playing track, the loop-in point is not where you expected it (and pressed the button). It jumped to the next full tick instead. Clearly audible with vocals.

The proposal is to allow smaller distances for ticks. E.g with Pioneers Recordbox you can set the QUANTIZE BEAT VALUE (1/16, 1/8, 1/4, 1/2, 1/1=default like Mixxx).

Now having a QUANTIZE BEAT VALUE of lets say 1/2, i can have additional 4 ticks in between the main ticks until the next bar begins.
Tick 1.0/4
Tick 1.5/4
Tick 2.0/4
Tick 2.5/4
Tick 3.0/4
Tick 3.5/4
Tick 4.0/4
Tick 4.5/4

[Jan Holthuis (holthuis-jan)]

@goddidignz Any progress yet? Fractional Quantize like 1/2, 1/4, 1/8, etc. would be really helpful for hotcue drumming, especially when the new macro feature lands.

[Swiftb0y (swiftb0y)]

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