Quantise beat loop start on nearest beat

[Dale]

Quantise for Loops behaves different to that for Play and HotCues.

Play and (Hot)Cues, when Quantise is enabled, snap to the Nearest beat.

Loops snap to the Previous beat.

Can we standardise behaviour so that triggering Loops also snap to the Nearest beat, rather than the Previous?

[Daniel Schürmann (daschuer)]

This was done on demand, in case the resulting loop would have zero length.

Do you have an issue with this behavior?

[Dale (dj-kaza)]

How can beatloop_enable ever result in a loop of zero length when it takes the length of the loop from beatloop_size property?

Yes I have an issue with it, I'm personally not used to purposely delaying my actions slightly when performing digital and I don't really think you should have to. Plus you can't even reliable enable a loop while paused at a hotcue on a beatmarker as sometimes it considered you to be just before the beat and thus makes a loop in the wrong location. This is very evidently incorrect behaviour.

I can see why loop_in should maybe always snap to the beatmarker before play_pos and loop_out to the one after but not beatloop_enable... (Please see my other Bug for a separate issue with the loop_out though.)

[Dale (dj-kaza)]

Some of that may be due to hotcues having been set in an old version where the analyse bug was present (when waveforms often used to be offset) as a couple of them where it looked like the marker was exactly on the beat and it exhibited that behaviour, after deleting and resetting the hotcue it triggers the loop in the right place. Still overall I think the points stand.

[Daniel Schürmann (daschuer)]

Ah, OK beatloops are the topic.
Currently they are enabled in a way that the play position is in the loop.

This is behaved differently compared to the loop in button which quantizes to the closes beat.
And I think there is actually a bug, because instead of a enable a catching loop, the track is seeked into the loop ahead.

So you want to have a catching beat loop in case the closest beat is ahead of the play position.
I think the current behaviour is legacy from the time Mixxx did not have catching loops.

This change will effect how the users activating beat loops. I am unsure if this is the expected behaviour.Do we now how other software handle this?

What do others think?

[Daniel Schürmann (daschuer)]

After the discussion here:
https://github.com/mixxxdj/mixxx/pull/2213#issuecomment-517131089
I have realized the real issue.
It behaves odd if the beatloop code results not exactly into the position if the cue point.

Since we have moved to a floating point transport engine, this may happen just because a floating point rounding issue in the code calculating the beat.

There is no doubt that at least this requires a fix.

The question is how long should be the "catching" around a beat marker.

Simply using the closest beat instead of the previous has a high impact to the way how loops at started when the track is running. Currently the loop is placed around the play position.
After this change it is placed ahead: "catching loop"

If this is expected anyway, it is a simple solution.

Thoughts?

[Philip Gottschling (goddisignz)]

As you've already seen in my PR my first thought was to use the closest beat (fraction) to start the loop. If the next beat marker is ahead of the current position use a "catching loop". If the previous beat is closer, it behaves like before.

I just imagine someone activating a beatloop a micro second before the next beat. He would probably expect the loop at that beat (catching solution). But what would one expect when he activates the beatloop right after the middle of two beats?
The previous one would right for someone thinking: "Oh, I forgot I want to start a loop.".
The next (closest) one would be right if you think: "I really don't want to miss that loop entry.".
Close to a beat things look pretty obvious to me, but if you are really off it is not so clear anymore.

I am curious how commertial tool behave in such or similar situations. I've been working on linux for so long that I have never tried Serato, Traktor, or Rekordbox.

Could a setting help? Like: Do you want to use the closest or previous beat for your beatloops?

[Owen Williams (ywwg)]

I believe I coded the logic for loops which always picks the previous beat. At the time it seemed to make sense but I can think of plenty of circumstances where the loop has been a beat off that this has annoyed me. I would be fine changing that to make pick the nearest beat instead. I don't think we need to sweat the mid-beat problem. We have loop slide buttons, and if the DJ hits the button at 51% and the loop is a beat off, they really only have themselves to blame.

[Daniel Schürmann (daschuer)]

OK, thank you for the input. So please Philip go ahead and thank you for taking care.

Please consider also fractional beats and the bug of manually setting loop in and out before passing the closes beat ahead.

[Daniel Schürmann (daschuer)]

I think breaking the sync part of this bug https://bugs.launchpad.net/bugs/1325157
Still happens the rest is legacy. I assume it will be fully fixed after this change.

[Dale (dj-kaza)]

What about this one with setting a Loop Out point? Or you only mean everything seems fixed/better with regards the beatloop function (and sorry for not being 100% clear that's what I meant originally.)

https://bugs.launchpad.net/mixxx/+bug/1837077

[Philip Gottschling (goddisignz)]

PR here: https://github.com/mixxxdj/mixxx/pull/2286

[Swiftb0y (swiftb0y)]

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