using closest beat for quantized looping breaks beatmatching

[Owen Williams]

re: revision 2984:

 "Make quantized beatloops start on the closest beat instead of the previous beat."

I was in the middle of a mix and pressed a hotkey to create an 8-bar loop. Because the closest beat was the next beat, Mixxx created a loop starting at the next beat. The playposition was therefore outside of the loop, so Mixxx resynced the position to be inside the loop, causing a break in sync.

I'm not sure if the previous behavior was more correct, or if we have to add a check to see if we are currently playing at the time the loop gets created. I think this might be a case where using the previous beat was the right thing to do. That, or somehow has to let the playposition reach the looping boundaries before enforcing them.

[RJ Skerry-Ryan (rryan)]

I just ran into the same problem when doing some mixing tonight. Not only
does it break sync but it also causes the deck to jump within the loop
which to the audience is a glitch.

On Thu, Dec 15, 2011 at 11:48 PM, Owen Williams <email address hidden> wrote:

> Public bug reported:
>
> re: revision 2984:
>
> "Make quantized beatloops start on the closest beat instead of the
> previous beat."
>
> I was in the middle of a mix and pressed a hotkey to create an 8-bar
> loop. Because the closest beat was the next beat, Mixxx created a loop
> starting at the next beat. The playposition was therefore outside of
> the loop, so Mixxx resynced the position to be inside the loop, causing
> a break in sync.
>
> I'm not sure if the previous behavior was more correct, or if we have to
> add a check to see if we are currently playing at the time the loop gets
> created. I think this might be a case where using the previous beat was
> the right thing to do. That, or somehow has to let the playposition
> reach the looping boundaries before enforcing them.
>
> ** Affects: mixxx
> Importance: Undecided
> Status: New
>
> ** Description changed:
>
> re: revision 2984:
>
> - Make quantized beatloops start on the closest beat instead of the
> - previous beat.
> + "Make quantized beatloops start on the closest beat instead of the
> + previous beat."
>
> -
> - I was in the middle of a mix and pressed a hotkey to create an 8-bar
> loop. Because the closest beat was the next beat, Mixxx created a loop
> starting at the next beat. The playposition was therefore outside of the
> loop, so Mixxx resynced the position to be inside the loop, causing a break
> in sync.
> + I was in the middle of a mix and pressed a hotkey to create an 8-bar
> + loop. Because the closest beat was the next beat, Mixxx created a loop
> + starting at the next beat. The playposition was therefore outside of
> + the loop, so Mixxx resynced the position to be inside the loop, causing
> + a break in sync.
>
> I'm not sure if the previous behavior was more correct, or if we have to
> add a check to see if we are currently playing at the time the loop gets
> created. I think this might be a case where using the previous beat was
> the right thing to do. That, or somehow has to let the playposition
> reach the looping boundaries before enforcing them.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/905106
>
> Title:
> using closest beat for quantized looping breaks beatmatching
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/905106/+subscriptions
>

[Sean M. Pappalardo (pegasus-renegadetech)]

This is what I was talking about in my comment on bug #881905: "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. Unless we can easily prevent that initial jump, I'm in favor of rolling back the change in r2984 of the 1.10 branch.

[Sean M. Pappalardo (pegasus-renegadetech)]

For the record, "somehow has to let the playposition reach the looping boundaries before enforcing them" is the correct way to fix this bug for good. (The previous behavior would start on the beat before the one you actually want.)

[RJ Skerry-Ryan (rryan)]

The closest-beat behavior causes this out of sync issue on all loops (not just beatloops). I dug in a little bit and it looks like there is a difference in the logic used in LoopingControl and the RAMAN. The RAMAN has logic that prevents seeking if the deck is going forward and before the loop-in or going in reverse and after the loop-out. The LoopingControl did not have this same logic. Fixing LoopIngControl to have the same logic as the RAMAN prevented the seeking-while-outside-the-loop issue that causes this desync / glitch.

I committed r2998 which fixes the bug while keeping the closest-beat behavior.

[Phillip Whelan (pwhelan)]

I knew there was a reason I had done it the way I did initially. Also,msince most of the time when I mix I am improvising. Iusually decide to add a beatloop after hearing the beginning of the section I want to loop. Adding the beatloop from before the dsired section would require intimate memorization of the current song, in my opinion.

Can anyone think of a good way to handle both useses?

[RJ Skerry-Ryan (rryan)]

As proposed in Bug #881905 a preference option for before/after/closest
might be the way to satisfy everyone.

On Fri, Dec 16, 2011 at 5:02 PM, Phillip Whelan
<email address hidden>wrote:

> I knew there was a reason I had done it the way I did initially.
> Also,msince most of the time when I mix I am improvising. Iusually
> decide to add a beatloop after hearing the beginning of the section I
> want to loop. Adding the beatloop from before the dsired section would
> require intimate memorization of the current song, in my opinion.
>
> Can anyone think of a good way to handle both useses?
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/905106
>
> Title:
> using closest beat for quantized looping breaks beatmatching
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/905106/+subscriptions
>

[Swiftb0y (swiftb0y)]

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