Mark first of every four bars of beatgrid

This is covered by two GSOC pull requests [WIP]:
https://github.com/mixxxdj/mixxx/pull/2961
https://github.com/mixxxdj/mixxx/pull/2930 (related)

Has there been any progress in the last months?
I still find this a very important and not so difficult thing to do.

Not much progress. Yes this is important, but it's actually a huge project, not a simple task.

Indeed, the PR https://github.com/mixxxdj/mixxx/pull/2961 is over 10.000 lines of changes. @Frabk Breitling: Did you already have time to test it?

Well I was looking at the code and thinking that if one could just change the color, width or length of every forth bar, it would already be very helpful in most cases.

@Jan No, I was not talking about the PR. I don't even understand what it is about.
I was just looking at how the markers are created and it seemed easy to modify them or adding another one on top of the first with four times the spacing but with a different appearance.

We've already been there and done that. Quick hacks are more distracting than useful.

https://github.com/mixxxdj/mixxx/pull/1529
https://github.com/mixxxdj/mixxx/pull/2186

Aha, but these PRs seem much more sophisticated than what I had proposed.
I don't see how my suggestion could be distracting and it looks straight forward and simple to implement for someone who has the build environment and knows this code.

I think done is better than perfect.

Without colors it is much more difficult to keep the orientation in a track.
That's why I switched to rekordbox.
But with colors I could finally switch back.

> I think done is better than perfect.

IIRC we once had a test build that just marked every 4th beat in a different color, and to my knowledge the testers found that more confusing then helpful because in many cases that beat was not the Downbeat. Hence, you'd also need editing capabilites, too. When you have editing capabilities, you need to store that data, which requires a protobuf format changes and a migration of all existing user beatmap/beatgrid data. This also makes it impossible to downgrade to an earlier version of Mixxx without losing all your beatgrids.

Therefore, we should design the protobuf format properly to not do more backwards-incompatible changes than needed.

Sounds good to me.
When you think about storing this data, it might be helpful to look at how it is stored in the rekordbox databases, because eventually Mixxx wants to import those, too.

Side comment: If storing additional information breaks backward compatibility you might want to consider a redesign of the storing method.

To my understanding only one additional integer is needed to determine which of the first four bars it is (1, 2, 3 or 4).

The problem is that Mixxx has two separate, incompatible methods of storing beat data. This needs to be fixed before changing the stored data format.

Would this be an opportunity to move to the rekordbox format?
Since Mixxx supports it now, this would be a way to reduce the number of supported formats.

> Would this be an opportunity to move to the rekordbox format?

First, we need to merge the disjunct BeatMap/BeatGrid classes. I'm already working on that right now.

Then we can evaluate what the best storage format would be. I'm not sure that Rekordbox's storage format (documented here: https://djl-analysis.deepsymmetry.org/rekordbox-export-analysis/anlz.html#beat-grid) is really the best way to store such data. I personally find Serato's format (documented here: https://github.com/Holzhaus/serato-tags/blob/master/docs/serato_beatgrid.md#beatgrid-markers) simpler and easier to extend.

But first we need to refactor because the two classes duplicate all work that needs to be done.

The rekordbox format might not be the best format but still the best choice, because it is most widely used, the de facto standard and safest choice for the future.
And it runs on all Pioneer players. Imagine how great it would be to plug a Mixxx USB drive in a Pioneer player!
Of course if you have the resources you can also implement the Serato format. However, resources are always limited.
Since I don't see where an independent Mixxx format could be useful I would give it up in favor of the others.

Hi! Has there been any progress on this feature in recent months?
Its a serious shortcoming which prevents me from using and testing Mixxx.

Well, there is https://github.com/mixxxdj/mixxx/pull/4489 which adds a basic keyframe-like editing workflow and also highlights downbeat. Support for legacy beatmaps is still incomplete, but it can already be tested.

Since https://github.com/mixxxdj/mixxx/pull/4489 has been labeled with stale, I am wondering if there has been any progress on this issue in recent months?

No progress recently. Do you have interest to pick some of this work up?

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