Adjust beatgrid pixel by pixel

[John doe]

It's not possible to accurately adjust the beatgrid with the
current behavior of beats_adjust_faster and beats_adjust_slower,
especially at the end of the track. A possible solution is
to adjust the beatmarkers pixel by pixel at the current position
in the track instead of adjusting the BPM by a constant value.

Please see the attached patch. The code modifications is
public domain.

[RJ Skerry-Ryan (rryan)]

Thanks for the patch, John Doe :).

As I understand it, your forumula is equivalent to:

new_bpm *= closest_beat / (closest_beat +/- audio_samples_per_pixel)

So, as closest_beat gets bigger (you are farther into the song) the adjustment gets smaller. I don't understand why this is desirable, could you say some more about this?

Am I wrong, that your needs would be met by having a finer grained beats_adjust_faster/slower control (e.g. an adjust by 0.005) ? Tying things to the track zoom level is slightly arbitrary IMHO :).

Some minor technical points:

- A track can be loaded into multiple decks at once, each with different waveform zoom levels. So storing the pixel-to-sample ratio in the TrackInfoObject isn't going to work reliably.

- The patch is against an old version of Mixxx. Could you please base future patches on the latest master branch? It's just about the same except src/trackinfoobject.cpp has moved to src/track/track.cpp.

- It would be ideal if you could submit a pull request on GitHub, since that makes it easier for team members to comment on specific lines of your code and helps us attribute your contributions to you via your commit author details. (though maybe you'd prefer to be anonymous given your LP username? :) ).

[John doe (johndoemixxx)]

This isn't a big problem when the track BPM is 120 and Mixxx
detects it as 129 or 131. But when the track BPM is 130.54
and Mixxx detects it as 130 it is a problem. I used to enter
track properties, guessed a BPM value, saved and looked at
the beatgrid and repeated until I guessed right.

I want the same result when I adjust the beatgrid no matter
where the playposition is in the track when I adjust the
beatgrid. The user-friendly solution is to adjust the
beatgrid one pixel to the left or to the right. That means
dynamic adjustment of the BPM value.

If you adjust the BPM with a constant value by calling
beats_adjust once, you will see the beatgrid move one pixel,
no move at all or more than one pixel depending on where you
are in the track and the number you add or subtract from
the BPM. If the constant is high, you can never get a
perfect beatgrid. If the constant is low you have to call
beats_adjust many times to see any change in the beatgrid
and when one adjustment doesn't result in a change in the
beatgrid there's no way to know if the adjusted BPM is
better than the previous BPM.

I think the dynamic approach is the best and most
user-friendly solution. That's why I changed the existing
functions. Have I missed some use cases? My use case is
getting a perfect beatgrid by playing a track from start
to end and adjust when I see the beat markers are starting
to appear before or after the beat.

[Daniel Schürmann (daschuer)]

How is the status here?
Is this already on GitHub?

[RJ Skerry-Ryan (rryan)]

John Doe -- do agree that the patch you posted is the equivalent of:

new_bpm *= closest_beat / (closest_beat +/- audio_samples_per_pixel)

As I understand it, this does not meet your criteria since you said:

"I want the same result when I adjust the beatgrid no matter where the playposition is in the track when I adjust the beatgrid."

If I understand correctly, you would want a formula that depends purely on audio_samples_per_pixel, not on closest-beat (since that scales depending on how far into a track you are).

This formula also is BPM dependent, since it increases the BPM by a percentage, whereas the code at head adjusts the BPM by a fixed offset (0.1). Is that desirable also?

I'm still unsure that we want to be tying adjustments to the zoom level. Is this need met by introducing a coarse/fine adjust like we have for the rate slider?

[John doe (johndoemixxx)]

By same result I mean one pixel to the right or one pixel to
the left.

Yes, that means one BPM adjustment at the beginning of a track
is not the same as a BPM adjustment at the end of the track when
you look at how much you adjust the BPM value. But the user
looks at the beatgrid on the screen where the playposition is
when adjusting. It is user-friendly that adjustment is smooth
anywhere in the track.

I have updated the patch and added pixel by pixel beatgrid
move because I also think that it is the most user-friendly
solution.

[Daniel Schürmann (daschuer)]

We have now controls for adjusting the beat grid.
This can be closed.

[Swiftb0y (swiftb0y)]

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