Decide on loop and hotcue quantize behavior

[Sean M. Pappalardo]

Testing with 1.10 r2859, with the loop quantize active (magnet symbol in Deere,) the Loop-In and Loop-Out points lock to the start of the next beat instead of the start of the current one as one expects. Also, it should quantize on quarter beats rather than whole ones.

[Owen Williams (ywwg)]

Additionally, I usually want to push the "4 bar loop" button at the *end* of the phrase, not the beginning. Maybe there has to be some sort of option to specify if loops are beginning-justified or end-justified? I agree that the loop point should never be ahead of the current play position, that doesn't really make sense musically.

[RJ Skerry-Ryan (rryan)]

Quantizing to anything other than a beat seems very odd to me. Do any other DJ software packages do this? I think before we do something like that, we will have to have some beat marks on the quarter and half notes so that it's clear what we're doing. Otherwise it will seem broken -- "I enabled quantize and it keeps dropping hotcues in between the beats!".

On the quantize to next-or-previous question, I think it's reasonable to have a preferences setting. I would also be curious to take a straw poll of other DJ software to see what the expected default behavior is. I think previous beat, next beat and closest beat are 3 reasonable options for this.

[RJ Skerry-Ryan (rryan)]

Also, this can't be in 1.10.1 since it seems pretty feature-y to me. Either it's 1.10.0 or 1.11.0.

For 1.10, I think changing the before/after behavior to whatever is the most commonly expected default behavior a DJ would want. Making a preference option counts as a feature to me, though.

[Sean M. Pappalardo (pegasus-renegadetech)]

Fixed in r2979 of the 1.10 branch. It works much more intuitively now. The only thing I would want to change is to have pre-sized loops start at the closest beat instead of the previous one, but currently doing that causes the deck to jump to the start of the loop, breaking the rhythm. To properly do that, we would need to prevent that initial jump.

[RJ Skerry-Ryan (rryan)]

I think we need to understand what the most likely user expectation is
here.

I asked some Traktor users and they said closest is how Traktor works. I
think Serato does not have snap-to-beat hotcues (I confirmed with at least
1 serato user) so the question is somewhat moot (I confirmed with some
other users). Does anybody know how others (VDJ, Torq, Mixvibes, etc.)
handle it?

On Fri, Dec 9, 2011 at 7:28 PM, Sean M. Pappalardo <
<email address hidden>> wrote:

> Fixed in r2979 of the 1.10 branch. It works much more intuitively now.
> The only thing I would want to change is to have pre-sized loops start
> at the closest beat instead of the previous one, but currently doing
> that causes the deck to jump to the start of the loop, breaking the
> rhythm. To properly do that, we would need to prevent that initial jump.
>
> ** Changed in: mixxx/1.10
> Status: In Progress => Fix Committed
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/881905
>
> Title:
> Loop and hot cue points should quantize to the closest beat
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/881905/+subscriptions
>

[RJ Skerry-Ryan (rryan)]

Beatloops work like this currently, the beat before the current position is selected as the start point. This is strange because if you are right on a beat, but slightly before it, the beatloop will start on the beat before the one you are effectively on. Phil had some arguments for this behavior a long time ago but I've forgotten them. Phil, can you chime in?

[Sean M. Pappalardo (pegasus-renegadetech)]

VirtualDJ LE does not quantize hot cues at all. With Smart looping enabled, it does not quantize the loop-in point either, but quantizes the loop-out point to the closest beat (relative to the loop-in point,) unless it's within a beat's distance, in which case the loop-out point goes to the closest 1/8 beat. (So a Smart loop is always a quantized _length_ in terms of beats, but where it starts is never quantized.)

As for beatloops, VDJ starts the loop exactly where the cursor is when you click the button (since loop-in is not quantized) and just makes the loop x beats long.

[RJ Skerry-Ryan (rryan)]

OK, interesting that they don't have it at all in VDJ LE. I assume the same
holds for VDJ Home?

Anyone know what VDJ pro does?

On Mon, Dec 12, 2011 at 2:06 AM, Sean M. Pappalardo <
<email address hidden>> wrote:

> VirtualDJ LE does not quantize hot cues at all. With Smart looping
> enabled, it does not quantize the loop-in point either, but quantizes
> the loop-out point to the closest beat (relative to the loop-in point,)
> unless it's within a beat's distance, in which case the loop-out point
> goes to the closest 1/8 beat. (So a Smart loop is always a quantized
> _length_ in terms of beats, but where it starts is never quantized.)
>
> As for beatloops, VDJ starts the loop exactly where the cursor is when
> you click the button (since loop-in is not quantized) and just makes the
> loop x beats long.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/881905
>
> Title:
> Loop and hot cue points should quantize to the closest beat
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/881905/+subscriptions
>

[RJ Skerry-Ryan (rryan)]

Closest-beat beatmatching can cause glitches in a mix since it can place a loop ahead of the current playposition. See Bug #905106

[Sean M. Pappalardo (pegasus-renegadetech)]

Did no one read my above comment? "The only thing I would want to change is to have pre-sized loops start at the closest beat instead of the previous one, but currently doing that causes the deck to jump to the start of the loop, breaking the rhythm. To properly do that, we would need to prevent that initial jump."

That's why I didn't commit that particular change.

[RJ Skerry-Ryan (rryan)]

Nope -- I either didn't fully read it or was too tired/dumb to understand :) so sorry about that. I believe Bug #905106 is fixed now.

[Swiftb0y (swiftb0y)]

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