Decide on loop and hotcue quantize behavior

Bug #881905 reported by Sean M. Pappalardo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Wishlist
Sean M. Pappalardo
1.10
Fix Released
Wishlist
Sean M. Pappalardo

Bug Description

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.

Related branches

Revision history for this message
Owen Williams (ywwg) wrote :

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.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

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.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

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.

Changed in mixxx:
milestone: 1.10.1 → none
summary: - Manual loop quantization is too coarse
+ Loop and hot cue quantization is too coarse
summary: - Loop and hot cue quantization is too coarse
+ Loop and hot cues should quantize to the closest beat
summary: - Loop and hot cues should quantize to the closest beat
+ Loop and hot cue points should quantize to the closest beat
Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote : Re: Loop and hot cue points should quantize to the closest beat

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.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 881905] Re: Loop and hot cue points should quantize to the closest beat

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
>

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: Loop and hot cue points should quantize to the closest beat

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?

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) 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.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 881905] Re: Loop and hot cue points should quantize to the closest beat

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
>

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: Loop and hot cue points should quantize to the closest beat

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

summary: - Loop and hot cue points should quantize to the closest beat
+ Decide on loop and hotcue quantize behavior
Changed in mixxx:
status: Confirmed → Triaged
assignee: nobody → Sean M. Pappalardo (pegasus-renegadetech)
Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

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.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

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.

Changed in mixxx:
status: Triaged → Fix Committed
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.