Quantise beat loop start on nearest beat

Bug #1752133 reported by Dale
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Committed
Wishlist
Philip Gottschling

Bug Description

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?

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Daniel Schürmann (daschuer) wrote :

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

Do you have an issue with this behavior?

Changed in mixxx:
status: Confirmed → Incomplete
importance: Medium → Undecided
Revision history for this message
Dale (dj-kaza) wrote :

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.)

Revision history for this message
Dale (dj-kaza) wrote :

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.

Changed in mixxx:
importance: Undecided → Wishlist
status: Incomplete → New
Revision history for this message
Daniel Schürmann (daschuer) wrote :

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?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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?

summary: - Quantise for Loops on nearest beat
+ Quantise beat loop start on nearest beat
Revision history for this message
Philip Gottschling (goddisignz) wrote :

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?

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

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.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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.

Changed in mixxx:
status: New → Confirmed
assignee: nobody → Philip Gottschling (goddisignz)
milestone: none → 2.3.0
Revision history for this message
Daniel Schürmann (daschuer) wrote :

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.

Revision history for this message
Dale (dj-kaza) wrote :

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

Be (be.ing)
Changed in mixxx:
milestone: 2.3.0 → none
Revision history for this message
Philip Gottschling (goddisignz) wrote :
Changed in mixxx:
status: Confirmed → In Progress
Changed in mixxx:
status: In Progress → Fix Committed
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/9160

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.