Beats: Add editing controls and show downbeats on scrolling waveforms [v2] #12343

fwcd · 2023-11-23T18:39:59Z

This is a rebase of @Holzhaus's #4489 onto main, a proof-of-concept implementation of downbeat markers and buttons for setting downbeats in the grid:

To do

Make this an off-by-default, marked-as-experimental feature in the settings, so people can play with it, without burdening regular users with its limitations (e.g. incorrect downbeat markers on non-4/4 tracks)
Address open feedback from [POC] Beats: Add editing controls and show downbeats on scrolling waveforms #4489

Deferred

Support non-4/4 (and changing time signatures): Definitely planned, but out-of-scope to keep this PR simple and to avoid changing the data model in a backwards-incompatible way for now

daschuer · 2023-11-24T09:38:02Z

src/track/beats.cpp

+int calculateBeatsTillNextMarker(const mixxx::Beats::ConstIterator& it,
+        mixxx::audio::FramePos nextMarkerPosition) {
+    const double numBeatsDouble = std::fabs(nextMarkerPosition - *it) / it.beatLengthFrames();
+    const int numBeatsInt = static_cast<int>(std::round(numBeatsDouble));


We round here twice. That may lead to a wrong overall rounding

Assuming every int can safely be represented as double, which is the case on the overwhelming majority of desktop platforms where int is 32-bit and double is a 64-bit IEEE-754 floating point and given that std::round is guaranteed to round to the nearest integer, this is usually safe. See https://stackoverflow.com/a/47153373/19890279.

I agree, however, that it might be more elegant to go with std::lround. We would still have to cast the long to an int though.

daschuer · 2023-11-24T09:42:30Z

src/track/beats.cpp

+    return numBeats + beatsPerBar - numExcessBeats;
+}
+
+int calculateBeatsTillNextMarker(const mixxx::Beats::ConstIterator& it,


The function name is misleading. How about:
int beatsTillBarNearPosition()

It looks like there is a need for "calculateBeatsTillNextMarker()" this should however be independent form a Bar.

daschuer · 2023-11-24T10:01:49Z

src/track/beats.h

+
+        /// Returns the current index of the beat in the bar.
+        int beatIndexInBar() const {
+            return m_beatOffset % beatsPerBar();


This assumes that the markers always align with a bar. This is probably musically correct.
However the model allows overlapping bars, and especially when we have dynamic beat-gits created in earlier version of Mixxx, we can have tempo changes in any place. We need to deal with it.

From the GUI perceptive, I would be in favour to require a bar for a temp change.

for cases where the tempo is increasing gradually, every beat may be a little faster or slower than the last. We should allow tempo changes on any beat marker.

Perhaps a second parameter would be useful to describe accelerando/ritardando in beats/s². On the other hand, the case might be too rare to justify this overhead.

I agree with @ywwg, tempo changes on every beat are common enough that we should support them. The problem I see is that it's probably not easy to retrofit into our current beatgrid model (that has no information about bars/measures) if we cannot interpret markers as downbeats. So we'd probably have to defer this for now, just like changing time signatures, which I'd very much be interested in having too.

I see a chance to integrate that.
For my understanding we need to add a an bar offset along with the beats per bar value.
This way we are still able to express the old free beat map with the new model

‖___|___|___|___‖___|__|__|__‖__|__|___|___‖___ M M M . 120bpm. 180 bpm 120 bpm barAt 0. barAt 3 barAt 2 beatsPerBar 4 beatsPerBar 4 beatsPerBar 4

it may well be that bpm-per-measure is "close enough" that it works with bpm speed-up/slowdowns or non-quantized tracks (disco etc). If we can test this situation early then we'll know if it's a problem or not. I have a few tracks that are my go-tos for difficult beatgrids, I can send them to you @fwcd if that helps

fwcd · 2023-11-29T16:15:03Z

By the way, another idea I had for making the implementation of downbeats + changing time signatures backwards-compatible would be to store downbeat/time-signature change markers in a separate map/db column, e.g. in terms of beat indices (as opposed to frames to avoid redundancy). That way we could safely iterate on that format without impacting older Mixxx versions until the 2.5 release. Thoughts?

(Would also be out-of-sope for this PR, but perhaps as a general direction)

daschuer · 2023-11-29T17:13:59Z

The downside is that this needs another lookup.
After a seek, we need to look up the beats from the time/sample position. Than we need to look up the downbeats Brom the beat numbers.

fwcd · 2023-11-29T19:45:15Z

That's a fair point, though that lookup should be fairly quick if we do a binary search. I don't have a good enough overview of the current implementation, but if this is something that only becomes relevant at seeks, my intuition would be that that should be performant enough to be worth trying?

I think maintaining a backwards-compatible data format would be a huge plus, since I worry that once we start changing the existing beatmap format, we'll (understandably) want to take our time to get it right to avoid messing up the databases of users/testers/developers and end up with massive PRs again...

ywwg · 2023-12-07T00:38:28Z

Maybe the new system could be used alongside the old one and we could have two beatgrids for one track. At track load time, the new code would first do a lookup in the new table, and if the beat grid is not there, look for it in the old table and then do an upgrade to the new format. Old code would ignore the new table and leave it alone.

fwcd · 2023-12-18T22:00:55Z

Did a quick rebase onto main to resolve the conflicts. Note that the downbeat markers currently only render with the legacy waveforms.

Maybe the new system could be used alongside the old one and we could have two beatgrids for one track. At track load time, the new code would first do a lookup in the new table, and if the beat grid is not there, look for it in the old table and then do an upgrade to the new format. Old code would ignore the new table and leave it alone.

I think that's a neat idea, though the redundancy in keeping both grids around might manifest itself in quite a bit of space in large libraries. Also, I'm a bit worried that if we bake this into our schema now, the decision to keep two grids around per track is going to be set in stone once we ship it (if we want to keep backwards compatibility). Another issue is that I am not sure how well this would "scale" to future changes of the beat grid scheme, since we would effectively have to add a new column every time (a table is probably overkill in any case).

Storing just the "new" information would solve this if we could figure out how to make the lookups performant enough.

JoergAtGithub · 2023-12-18T22:12:39Z

I think we should import the old library at the first start of the new version. We can ask the user in a dialog, if he wants to delete the old library or delete it.

fwcd · 2023-12-18T22:16:13Z

Yeah, the question would be if we could make it backwards-compatible to avoid introducing a "hard" migration. I could see this being convenient, especially for developers which like to hop between different versions. The fact that I can run 2.3 without switching databases has proven useful several times while diagnosing issues.

JoergAtGithub · 2023-12-18T22:19:03Z

Or we add the read functionality for the new format in Mixxx 2.5, but the downbeat feature that writes this format one release later.

fwcd · 2023-12-18T22:22:28Z

I am not quite following, how would we use downbeats if we can't write them anywhere? Use a fresh grid every time the user opens the track?

JoergAtGithub · 2023-12-18T22:24:26Z

Than 2.5 would only show the beats, but read from the new library format, ignoring all new elements like downbeats.

fwcd · 2023-12-18T22:32:23Z

Ah I see, we would still break backwards compatibility with all versions older than 2.5 in that case though. I agree that it would be an option, but I also think it would be nice if users already had something to play around with. The specifics of the format should ideally be able to evolve alongside the UI as we figure out more details.

ywwg · 2023-12-21T16:10:32Z

I like the idea of allowing the user to choose whether to keep the old grids or delete them. For me, disk space is cheap, and even the 4.4G I have in my analysis directory is not a big deal. We could also give the user the option to delete the old beats later if they kept them during the upgrade. And when 2.6 comes out we can say "hey if you never plan on using 2.4 again we can delete this data".

ywwg · 2023-12-21T16:11:22Z

A two-version migration for the hard format change is a great idea, +1!

github-actions · 2024-03-21T00:07:35Z

This PR is marked as stale because it has been open 90 days with no activity.

ywwg · 2024-03-21T13:48:28Z

@fwcd do you think you can work on this during the dev phase?

acolombier · 2024-06-03T14:46:28Z

@fwcd I'd like to use your work as foundation for #13308, do you have interest in finishing this work or would you be okay with me trying to finish it?

fwcd · 2024-06-03T14:50:36Z

Sure, feel free to take over this PR (which is mostly just a rebase of @Holzhaus, nothing really novel here). I'm a bit short on time right now, so if you're interested, go ahead

fwcd · 2024-06-05T22:43:03Z

Closing in favor of #13330

github-actions bot added skins engine waveform labels Nov 23, 2023

fwcd added beatgrid skins engine and removed skins engine labels Nov 23, 2023

fwcd changed the title ~~[v2] Beats: Add editing controls and show downbeats on scrolling waveforms~~ Beats: Add editing controls and show downbeats on scrolling waveforms [v2] Nov 23, 2023

fwcd mentioned this pull request Nov 23, 2023

[POC] Beats: Add editing controls and show downbeats on scrolling waveforms #4489

Closed

2 tasks

daschuer requested changes Nov 24, 2023

View reviewed changes

daschuer reviewed Nov 24, 2023

View reviewed changes

Holzhaus added 8 commits December 18, 2023 21:40

Beats: Add initial read-only support for downbeats

31cac25

Beats: Add method to get the iterator to a beat close to a position

0e6dd48

BpmControl: Add Beats editing controls

cbabd52

WaveformRenderBeat: Add support for rendering downbeats

65441e9

LateNight: Set downbeat color in skin.xml

7d0ca41

WaveformRenderBeat: Pass QVector directly to drawLines()

8f22757

Show markers on waveforms [WIP]

f0054fe

LateNight: Add buttons for setting/removing beats markers [WIP]

d6c5070

fwcd force-pushed the newbeats-downbeats-rebase branch from b23c33e to d6c5070 Compare December 18, 2023 21:51

ronso0 mentioned this pull request Feb 26, 2024

Usability: Improved Beat Counting Visibility #12879

Closed

github-actions bot added the stale Stale issues that haven't been updated for a long time. label Mar 21, 2024

github-actions bot removed the stale Stale issues that haven't been updated for a long time. label Mar 23, 2024

Swiftb0y mentioned this pull request Jun 1, 2024

Multiple beat grid on a single track #13308

Open

acolombier mentioned this pull request Jun 5, 2024

Beats: Add editing controls and show downbeats on scrolling waveforms [vn+1] #13330

Open

4 tasks

fwcd closed this Jun 5, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Beats: Add editing controls and show downbeats on scrolling waveforms [v2] #12343

Beats: Add editing controls and show downbeats on scrolling waveforms [v2] #12343

fwcd commented Nov 23, 2023 •

edited

Loading

daschuer Nov 24, 2023

fwcd Nov 29, 2023 •

edited

Loading

daschuer Nov 24, 2023

daschuer Nov 24, 2023

daschuer Nov 24, 2023

ywwg Nov 27, 2023

JoergAtGithub Nov 27, 2023

fwcd Nov 29, 2023

daschuer Nov 29, 2023

ywwg Dec 2, 2023

fwcd commented Nov 29, 2023 •

edited

Loading

daschuer commented Nov 29, 2023 •

edited

Loading

fwcd commented Nov 29, 2023 •

edited

Loading

ywwg commented Dec 7, 2023

fwcd commented Dec 18, 2023

JoergAtGithub commented Dec 18, 2023

fwcd commented Dec 18, 2023

JoergAtGithub commented Dec 18, 2023

fwcd commented Dec 18, 2023

JoergAtGithub commented Dec 18, 2023

fwcd commented Dec 18, 2023

ywwg commented Dec 21, 2023

ywwg commented Dec 21, 2023

github-actions bot commented Mar 21, 2024

ywwg commented Mar 21, 2024

acolombier commented Jun 3, 2024 •

edited

Loading

fwcd commented Jun 3, 2024

fwcd commented Jun 5, 2024

Beats: Add editing controls and show downbeats on scrolling waveforms [v2] #12343

Beats: Add editing controls and show downbeats on scrolling waveforms [v2] #12343

Conversation

fwcd commented Nov 23, 2023 • edited Loading

To do

Deferred

Choose a reason for hiding this comment

fwcd Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fwcd commented Nov 29, 2023 • edited Loading

daschuer commented Nov 29, 2023 • edited Loading

fwcd commented Nov 29, 2023 • edited Loading

ywwg commented Dec 7, 2023

fwcd commented Dec 18, 2023

JoergAtGithub commented Dec 18, 2023

fwcd commented Dec 18, 2023

JoergAtGithub commented Dec 18, 2023

fwcd commented Dec 18, 2023

JoergAtGithub commented Dec 18, 2023

fwcd commented Dec 18, 2023

ywwg commented Dec 21, 2023

ywwg commented Dec 21, 2023

github-actions bot commented Mar 21, 2024

ywwg commented Mar 21, 2024

acolombier commented Jun 3, 2024 • edited Loading

fwcd commented Jun 3, 2024

fwcd commented Jun 5, 2024

fwcd commented Nov 23, 2023 •

edited

Loading

fwcd Nov 29, 2023 •

edited

Loading

fwcd commented Nov 29, 2023 •

edited

Loading

daschuer commented Nov 29, 2023 •

edited

Loading

fwcd commented Nov 29, 2023 •

edited

Loading

acolombier commented Jun 3, 2024 •

edited

Loading