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

acolombier · 2024-06-05T17:00:27Z

This PR is based on @fwcd 's PR #12343, itself based on @Holzhaus 's #4489 PR.

Kooha-2024-06-07-18-43-20.mp4

This attempt TL;DR; is: do not disrupt the way the beat grid currently works

This is how this attempt differs from the previous one:

BPM doesn't get change when adding or removing a new marker
Adjusting the BPM will have a consistent behaviour whether editing a specific marker or the end of track marker
Faster/slower BPM will adjust the BPM by 0.01, and will auto repeat if the button stays pressed for more than half a second
Faster/slower BPM will behave like above but with a 0.1 if the right click is used instead
Translating the grid will only impact the current marker, and the button can stay pressed to repeat
Beatgrid markers can be turn on and off as waveform options
Beat colours support alpha

TODO:

Fix Serato beat grid import
Store the bar length using the beatmap
Implement missing usecase
Fix the "last beat" not displayed when the next marker grid uses a different beat length

Fixes #13308 and #10164

Disclaimer:
I know there was a lot of discussion on these types of change in each of the above PRs as well as in the Zulip thread that goes with it. I'm sorry, but I only read the latest messages of each as there was a few hundreds of them, going over a few years of activity. Apologies if this proposal contains approaches that have been discussed and ruled out already.

JoergAtGithub · 2024-06-05T22:37:46Z

Just for completeness, #4489 was just a small part splitted of from this work: https://github.com/mixxxdj/mixxx/wiki/Measures-Downbeats-Bars-And-Phrases

Swiftb0y

haven't been able to look at the meat (beats.cpp) yet. In the meantime, can you take care of CI failures. The inline annotations produced make it hard to review (and they need to resolved anyways, so better sooner than later).

src/waveform/renderers/waveformrenderbeat.cpp

src/waveform/renderers/allshader/waveformrenderbeat.h

acolombier · 2024-06-06T16:47:54Z

Thanks for looking into this @Swiftb0y this quick!

With my latest commit, I should fix most of the CI issues + failing test, and also started cleaning up some of the mess. Before looking too much into the code, I'd been keen to hear whether or not we are okay with approach I've taken from a UX perspective, and perhaps also gets some user testing first. As I said in introduction, I know there was a lot of discussion on the matter and I'd like to make sure this doesn't end up abandoned as well.

JoergAtGithub · 2024-06-06T20:57:44Z

It crashes here, if I try to place a marker before the very first marker:

acolombier · 2024-06-07T17:32:48Z

With the last commit, I have introduce customizable beats per bar for each markers. To do so, I'm using a "double beat" in the beat map, meaning a beat with the same position that the previous one. This is used to infer the bar length.

Pro: no need for a proto change
Con: If you revert and try to load a track using a custom bar length, you will get an assert here. This will lead the grid being invalidated, same than if we were introducing a new proto version anyway.

@JoergAtGithub I tried many things but couldn't reproduce it. Could you please provide me with some steps and maybe a short recording? I'm probably missing a settings or something.

JoergAtGithub · 2024-06-07T18:32:31Z

This time I got antoher assert:
DEBUG ASSERT: "markerIt != markers.end()" in function class std::optional<class std::shared_ptr > __cdecl mixxx::Beats::tryRemoveMarker(class mixxx::audio::FramePos) const at D:\mixxx-main-worktree\src\track\beats.cpp:926

JoergAtGithub · 2024-06-07T18:46:35Z

And now I got the original again:

DEBUG ASSERT: "beatFraction > 0 && beatFraction < 1" in function bool __cdecl mixxx::Beats::findPrevNextBeats(class mixxx::audio::FramePos,class mixxx::audio::FramePos *,class mixxx::audio::FramePos *,bool) const at D:\mixxx-main-worktree\src\track\beats.cpp:460
Unhandled exception at 0x00007FFBFE405438 (Qt6Core.dll) in mixxx.exe: Fatal program exit requested.

acolombier · 2024-06-07T18:49:29Z

Right, my fault, DEBUG_ASSERTIONS_FATAL had gone OFF for some reason. I can reproduce both now.

The first one is related to the Fix the "last beat" in the description, the second one seem to be a wrong offset. I'll let you know when I get both sorted.

JoergAtGithub · 2024-06-07T18:56:04Z

Con: If you revert and try to load a track using a custom bar length, you will get an assert here. This will lead the grid being invalidated, same than if we were introducing a new proto version anyway.

The link "here" doesn't point to a particular line of code. But I wonder if it's possible to add some code to the 2.4.2 release that just prevents the grid invalidation. And than merge this PR with the new beatgrid feature into 2.6.

acolombier · 2024-06-07T19:00:17Z

Fixed

acolombier · 2024-06-09T13:51:05Z

@JoergAtGithub I believe fixed most of the asserts and added some tests to cover the new introduced use-cases. I would appreciate if you could give it another go 🙏

src/track/beats.cpp

acolombier · 2024-06-10T08:23:17Z

I wonder if it's possible to add some code to the 2.4.2 release that just prevents the grid invalidation. And than merge this PR with the new beatgrid feature into 2.6.

It's worth to highlight the invalidation would only happen if one:

Uses custom measure size in 2.6
Reverts to 2.5

So while it feels quite an edge case, it may also feels fairly natural to need to regenerate the beatgrid to the user, so perhaps worth keeping as is.

JoergAtGithub · 2024-06-19T10:53:54Z

I tested again, and no asserts occured anymore!

It's worth to highlight the invalidation would only happen if one:
* Uses custom measure size in 2.6

* Reverts to 2.5
So while it feels quite an edge case, it may also feels fairly natural to need to regenerate the beatgrid to the user, so perhaps worth keeping as is.

The missing backward compatibility, was one of the main reasons, why the predecessor PRs got never merged. We need an commonly agreed strategy here.
Personally, I have no strong preferences here, as long as the final implementation is not compromised by the legacy.

JoergAtGithub · 2024-06-19T11:22:39Z

The markers in the waverforms are difficult to recognize. The visual representation in the original PR #2961 was more clear in my opinion: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/beatgrid.20editing.20UI/near/206216183

acolombier · 2024-06-19T18:12:21Z

I tested again, and no asserts occured anymore!

Great to hear!

Personally, I have no strong preferences here, as long as the final implementation is not compromised by the legacy.

Make sense to me. What do you think of my proposition of backward compatibility, except if the multiple bar length feature is used?

The markers in the waverforms are difficult to recognize

Yeah it could be better I agree. The colour of the bar marker can be customised by the them. By default I wanted to have something not striking to much ( like the original red colour used before), but I guess we could find a middle ground.
Adding custom drawing (like the triangle in the previous version) might be too much and also not as straight forward to do as just a custom colour, than can easily be customised.

acolombier · 2024-06-19T18:14:06Z

Overall, are we happy with getting this PR in as is? Just wondering if I should start looking at making it production ready, and clean up the implementation/fix conflict or of there is still outstanding controversial aspects.

Swiftb0y · 2024-06-19T19:18:32Z

Well, the primary thing I'm confused about currently are the complications around lastBeatsPerBar, but I haven't read the corresponding code thoroughly enough yet.

Swiftb0y · 2024-06-19T20:18:11Z

One of the primary changes are that you changed the beatmarkers to store the beatlength instead of the total beatcount, right? Can you share some of the rationale behind that or link me to a previous discussion?

acolombier · 2024-09-19T22:30:58Z

I broke down the feature in two PR now (follow up here) and managed to reduce slighly the size.

Hopefully this is now easier to review and merge 🤞

Swiftb0y

I'm not familiar with the code in question so I'm the wrong person to review this for anything but surface-level comments.

src/test/beatstest.cpp

src/track/beats.h

Swiftb0y · 2024-06-19T19:13:08Z

src/track/beats.h

+    enum class TempoAdjustment {
+        Faster = 0b01,
+        Slower = 0b10,
+        // The following variant are used to indicate wider adjustment requests
+        MuchFaster = 0b100 | Faster,
+        MuchSlower = 0b100 | Slower,
+    };


I don't see the value in this flag-style approach, after all, what would 0b11 mean? But I don't see any downside right now either.

Yeah, that's a good point. The reason for doing so, as oppositie to use maybe on bit to define the direction was to allow a null type but I guess that would make sense.

Do you think the following would make more sense? The reason for that flag-style approach was to have meaningful paramater, opposition to a bool, bool signature.

Suggested change

enum class TempoAdjustment {

Faster = 0b01,

Slower = 0b10,

// The following variant are used to indicate wider adjustment requests

MuchFaster = 0b100 | Faster,

MuchSlower = 0b100 | Slower,

};

enum class TempoAdjustment {

Faster = 0b1,

Slower = 0b0,

// The following variant are used to indicate wider adjustment requests

MuchFaster = 0b10 | Faster,

MuchSlower = 0b10 | Slower,

};

I saw that there is some more complicated bit manipulation in the code after. I think it would make sense to encapsulate that by wrapping the enum in a class and the implementing the possible operations as simple member functions. This shouldn't introduce a huge amount of boilerplate and would the code more robust and easier to understand.

src/track/beats.h

Swiftb0y · 2024-06-20T19:11:46Z

src/track/beats.h

+        int beatIndexInBar() const {
+            return m_beatOffset % beatsPerBar();
+        }


we should look into how often this is called, just because the modulo might get expensive.

I will have a look.

don't waste your time on it for now, it was just a thought. I'm actually more concerned that the iterator operations may be inefficient (because operations such as -- actually need $O(n)$ instead of $O(1)$.

src/track/beats.h

src/track/beats.cpp

Swiftb0y · 2024-09-20T11:39:16Z

src/track/beats.cpp

+    // Track: |--------------------------------------------------------|
+    //        |   |   |   |   |   ||  |  |  ||  |  |  ||   |   |   |   ||


I'm not familiar with the double beat concept. Where do they come from, the analyzer?

No, this is how the beat marker is translated in the BeatMap: two marker at the exact same positions. By default, the analyser will only issue single beat marker, and so the deserialisation process will infer that the first beat is a beat marker and that the bar length is 4 as default. However, if you set a beat marker (Using the CO, UI available in next PR), it will be serialised using this double beat in the map, the 4-beat bar will be relative to that beat, If you have an other double beat marker withing the acceptable range ([2-32]) it will be used to inferred the bar length, starting from that beat till the end of the track (or the next marker)
I appreciate it may feel a bit complicated, but that was the only way I could reuse the existing proto definition and make that change non-breaking (and I could read it was a point of contention in the past attempt of addressing that feature...)

Not sure about this.

The main reason for not changing the serialized beatmap format is to stay compatible with other mixxx versions (since we were not sure if this approach for downbeat is really the way to go). Although this PR doesn't change the beatmap format, it actually results in beatmap data that never occurred before. Will older versions of Mixxx be able to handle the double beats gracefully?

If not, we might as well add a new "is_marker" field or revamp the serialization format entirely. Not against this, just wanted to point out that sticking to the old format becomes pointless if it becomes incompatible anyway.

Will older versions of Mixxx be able to handle the double beats gracefully?

From my testing with 2.4 and 2.5, yes it does. The only issue is a DEBUG_ASSERT, but nothing else which seems to impact the correct functionning.

we might as well add a new "is_marker" field

That would definitely be cleaner. Do we have consnsus on adding a new proto definition? AFAIK, we should be able to add this without issue a new versionning either and only make the most of protobuf field versionning here, so that sounds minimal enought to be acceptable here. Wdyt?

I appreciate it may feel a bit complicated, but that was the only way I could reuse the existing proto definition and make that change non-breaking

I like the idea to have a compatible format. I am just afraid that some sync and quantize code will be confused by the double beat. What are the alternatives?

message BeatMap { repeated Beat beat = 1; }

Will an extra array for the bar lines also work?

message BeatMap { repeated Beat beat = 1; optional repeated Beat bar_line = 2; }

It doesn't not, since the double beat is only used to detect marker and bar length (beats per bar). The problem is, When storing the beeatmap, we store the interpolated beats as well. Markers are transformed in double-beat, so we could add two new properties to Beat? Something like ismarker and beatPerBar?

I'm wondering if we could just go with this in a first place, and then introduce the new proto definition if it does turn out to break something. After all, that is what alphas are for ;-)

ywwg · 2024-09-20T17:45:11Z

I broke down the feature in two PR now (follow up here) and managed to reduce slighly the size.

🙏🏻 thank you!

JoergAtGithub · 2024-09-20T21:56:21Z

I'm not familar with this part of the code. AFAIK @Holzhaus is the expert here.

acolombier · 2024-10-08T18:36:20Z

@Holzhaus are you interested in reviewing this?
Anyone else from the @mixxxdj/developers confident giving that a go? It'd be nice not to left that PR to get too far behind and get conflict growing.

Holzhaus · 2024-10-08T18:37:59Z

Yes, I promise I will review this weekend.

Holzhaus

Thanks for the PR. I have to admin that I cannot comment on the dowbeat support tbh, because that seems to have been removed from this PR (as well as the skin changes). Right-click-and-holding the beats adjustment buttons also didn't work.

Code looks mostly good to me (apart from some minor nits).

I'm not entirely sure regarding usability. My most common usecase for which I see the need to edit the beatgrid are following:

Beatgrid shifted by a half beat
Beats are detected correctly at the start of the track, but slowly go out of sync later on in the track.

To fix 1) I can just use the beats translation. I usually use beats_translate_curpos or beats_translate_match_alignment.

For 2), my idea for #4489 was that I can fix the situration by moving the playpos to a late beat in the track, click beats_set_marker (mapped to a button on my controller) and the beatgrid autostretches to accomodate this. I might have to adjust the number of beats between the two markers, but you get the idea.

This PR does not do that, as described in the PR description:

BPM doesn't get change when adding or removing a new marker

This makes 2) kind of cumbersome, because now the new marker is kind of pointless: It doesn't really help because you still need to adjust manually using the beats adjust faster/slower buttons, and you cannot be sure that the number of beats between the two markers is a multiple of four without checking youself (the latter might be resolved by adding back downbeat display).

Here's a smal video to show what I mean:

Peek.2024-10-13.13-26.mp4

I have to admit that I didn't really follow the discussion, so maybe there is a good reason for this behavior. But this way of editing the beatgrid seems to be not a good fit for my use cases (or I don't know how to use it properly). Anyway, I'm not against this PR at all, so you have green light from my side if the other team members like the editing workflow.

src/engine/controls/bpmcontrol.cpp

Holzhaus · 2024-10-13T10:40:53Z

src/track/beats.cpp

+    // Track: |--------------------------------------------------------|
+    //        |   |   |   |   |   ||  |  |  ||  |  |  ||   |   |   |   ||


Not sure about this.

The main reason for not changing the serialized beatmap format is to stay compatible with other mixxx versions (since we were not sure if this approach for downbeat is really the way to go). Although this PR doesn't change the beatmap format, it actually results in beatmap data that never occurred before. Will older versions of Mixxx be able to handle the double beats gracefully?

If not, we might as well add a new "is_marker" field or revamp the serialization format entirely. Not against this, just wanted to point out that sticking to the old format becomes pointless if it becomes incompatible anyway.

src/track/serato/beatgrid.cpp

acolombier · 2024-10-13T11:52:42Z

Thanks for the in depth review @Holzhaus !

because that seems to have been removed from this PR (as well as the skin changes)

This was requested above - split the PR to reduce the amount of changes. UI changes can be seem in this PR. The branch also include the commit from this PR so it might make it easier to test! Apologies, I should have updated the description accordingly.

Right-click-and-holding the beats adjustment buttons also didn't work.

I'll look into that. It could be that I broke it when I moved all the UI changes to a follow up PR.

click beats_set_marker (mapped to a button on my controller) and the beatgrid autostretches to accomodate this.
[...] I have to admit that I didn't really follow the discussion, so maybe there is a good reason for this behavior

This approach was preventing using this feature on a few of my tracks, and didn't allow a workaround. This was including tracks with

Change of BPM
Beat shift

With the current approach, as your rightfully demoed, this covers all usecase, although I appreciate for yours, it makes it a little bit less smooth. What do you think about me adding another CO (e.g beat_stretch) or a new value for beat_set_marker (1 would behave like it does, 2 would stretch the previous BPM to align with the new marker, as it was with #4489). Personally, I would vote for a dedicated CO just to not over fit behaviours and potentially create confusion. Wdyt?

Holzhaus · 2024-10-13T12:45:00Z

This was requested above - split the PR to reduce the amount of changes. UI changes can be seem in this PR. The branch also include the commit from this PR so it might make it easier to test! Apologies, I should have updated the description accordingly

Yup, smaller PRs are easier to review. Thanks.

What do you think about me adding another CO (e.g beat_stretch) or a new value for beat_set_marker (1 would behave like it does, 2 would stretch the previous BPM to align with the new marker, as it was with #4489). Personally, I would vote for a dedicated CO just to not over fit behaviours and potentially create confusion. Wdyt?

Sounds reasonable, but for a controller-based workflow, the number of buttons is limited and I'd like to avoid that the mapping creator make the choice which CO to map because the library/use cases might be different for other users with the same controller.

If there already is a marker at the current play position, beats_set_marker is a no-op, right?

What do you think about calling beats_set_marker at a position where a marker already exists to stretch the beats between that marker and the preceding marker? No sure if this would be too confusing, but it would require less buttons to cover both use cases.

acolombier · 2024-10-13T20:06:24Z

for a controller-based workflow, the number of buttons is limited and I'd like to avoid that the mapping creator make the choice which CO to map because the library/use cases might be different for other users with the same controller.

I guess one could always bind the beats_set_marker on press, and beats_stretch on long press?

What do you think about calling beats_set_marker at a position where a marker already exists to stretch the beats between that marker and the preceding marker?

My fear is that there could be risk of accidentally breaking the grid. It's worth to say that this code was written before beats_undo_adjustment was introduced so we could also decide to go ahead with your suggestion, and latter on ensure that undo is well supported and allow undoing this.
Additionally, we could also add a setting in parameter that make beats_set_marker stretch on existing marker, so by default it would not and only beats_stretch would do so, but someone with a limited set of mappable button could decide to overload beats_set_marker's behaviour. Does that sound like a reasonable plan?

Holzhaus · 2024-10-13T22:27:19Z

Yup, sounds good. I think there are many ways to support such use cases. We could also add a config option to modify the default behavior. Anyway, nothing in scope of this PR.

There are failing checks now. If you fixup the commit, I suppose this is ready to merge.

src/audio/types.h

src/track/beats.h

acolombier · 2024-10-14T20:44:34Z

Anyway, nothing in scope of this PR.
[..] I suppose this is ready to merge.

Great to hear! I have added some TODO note in the code to link with that follow up task. I have created an issue to capture that discussion and make sure this is addressed later.

acolombier · 2024-10-15T08:10:38Z

@Holzhaus are you happy to approve this before I squash the fixups?

src/track/beats.cpp

src/audio/types.h

daschuer · 2024-10-15T15:46:54Z

src/engine/controls/bpmcontrol.cpp

@@ -117,6 +143,34 @@ BpmControl::BpmControl(const QString& group,
            this,
            &BpmControl::slotTranslateBeatsMove,
            Qt::DirectConnection);
+    m_pBeatsSetMarker = std::make_unique<ControlPushButton>(
+            ConfigKey(group, "beats_set_marker"), false);


The "marker" in imprecise.
We may use "bar line", in German "Taktstrich". That would be easier to undertsand for me.
https://en.wikipedia.org/wiki/Bar_(music)
Is that ment here?

So we may call it beats_set_bar_line

We may also consider to introduce a new bar prefix for
bar_line_set
bar_increase_lenght

An alternative would be downbeat
https://en.wikipedia.org/wiki/Beat_(music)#Downbeat_and_upbeat
`downbeat_set'

This works in the CO interface but is a translator trap because there does not exist a precise translation in
German and other languages. But for "counting downbeats" I would say in German "Takte Zählen" = "Counting bars". The Downbeat itself is "Die Eins" = "The One".

How is the situation in france?

This is not the same. You don't need to set every bar line manually, they are interpolated based on the position of the marker and the BPM. The "Marker" is the frame position where the first downbeat with new settings is. I think the term is fine. Using established terminology that doesn't fit exactly can lead to more confusion.

You don't need to set every bar line manually

That's clear, but you also set at least the first. And it is about the alignment of the bars.
So I think my proposal is not completely wrong.

Is the an other way to relate "beats_set_marker" to bars?
Maybe "beats_start_new_bars" or something.

I think it makes sense to keep the clear distinction between markers and bars/downbeat as @Holzhaus rightfully pointed out.
There is is also the fact that marker define a new grid, so in the case where the marker is set in between two beats, the new grid will start of tempo compare to the previous grid. As a reminder, this is a requirement to deal with tracks that have variable tempo or may shift by a bit fraction in the track.

Ah OK, in is just a new grid start bar line. I thought this sets a bar line and then other bar lines are interpolated form that.

The essence of my first comment is that "beats_set_marker" reads as if you set a beat marker which is just the vertical line we had always marking beats. I think this is a real issue and needs to be solved.

proposals:
"beats_set_bar_change"
"beat_signature_change"
"beats_set_bars_start"
"beats_mark_bar_change"

The visuals are implications here.

Right, here we are looking to the CO interface.
I'm interested in the future plans to align our requirements.

As I have understood with the new "beats_set_change_marker" CO we can adjust either adjust tempo slightly, or mark a signature change which is a double bar line on a musical sheet.

I consider this to be sufficient for all use cases, in a way that all change markers shall be visible on the waveform. But I like to confirm it with you to avoid future discussions. (Compared to an additional interface which allows to move single beats)

We have two use cases regarding tempo changes:

A const beat grid which aligns at the start and end but is off in the middle.

User can find the tempo change positions, preferably pick a downbeat not on the grid and mark it using the new control. The beast before and after, schall be adjusted to hit this new beat marked with e.g a double bar line.

A non const beat grid where the beats are more likely on time but with issues making "tshank" instead of "boom". The latest detector is able to group beats with the same tempo. I consider it very much desired to not change tempo in every beat to avoid youling in followers.

User may want to explicitly mark tempo changes and combine regions if similar tempo to one region. After finishing, it is probably desired to be in the same state as 1. User should also be able to align change markers to downbeats. Technical he is free to mark every beat, but that should be an exception.

Can you confirm that?

I think Mixxx should make it hard to create a padding bar, that does not match the previous and not the follower bars. In case users really wants it, they can mark the start of this padding bar as well.

What do you think?

I guess we could make the marker align on the previously set grid if quantize is on. IMO that makes sense indeed to guide users to keep, their beatgrid as aligned as possible.
Could we please address that as a follow up PR tho? I really would like to get this merge ASAP to set the base for future work related to beatgrid.

I don't have demands for additional changes here, so that's fine. I just like to confirm that we are on the right track. @Holzhaus, can you confirm that as well?

I have pushed the CO update. Are we happy to move forward now?

Yes, thank you.

acolombier · 2024-10-23T06:56:54Z

Rebased and ready to merge!

src/skin/legacy/tooltips.cpp

Co-authored-by: Jan Holthuis <[email protected]>

ywwg · 2024-10-24T15:56:03Z

@daschuer you still have changes-requested marked, are all your notes addressed?

daschuer · 2024-10-25T05:11:38Z

A manual test is pending. I hope I will find time this weekend. Did other reviewers testing regarding the new beat format?

github-actions bot added skins engine ui code quality preferences waveform labels Jun 5, 2024

fwcd mentioned this pull request Jun 5, 2024

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

Closed

2 tasks

Swiftb0y reviewed Jun 6, 2024

View reviewed changes

src/waveform/renderers/waveformrenderbeat.cpp Outdated Show resolved Hide resolved

src/waveform/renderers/waveformrenderbeat.cpp Outdated Show resolved Hide resolved

src/waveform/renderers/allshader/waveformrenderbeat.h Outdated Show resolved Hide resolved

acolombier force-pushed the newbeats-downbeats-rebase branch from 636a042 to b1967d9 Compare June 6, 2024 17:29

acolombier force-pushed the newbeats-downbeats-rebase branch 2 times, most recently from 94c256f to e06279c Compare June 9, 2024 15:24

acolombier commented Jun 9, 2024

View reviewed changes

src/track/beats.cpp Outdated Show resolved Hide resolved

acolombier force-pushed the newbeats-downbeats-rebase branch from e06279c to bc15b8d Compare June 9, 2024 16:39

acolombier force-pushed the newbeats-downbeats-rebase branch from bc15b8d to 693b0e4 Compare September 19, 2024 22:26

acolombier mentioned this pull request Sep 19, 2024

Support for downbeat in LateNight #13670

Open

acolombier marked this pull request as ready for review September 19, 2024 22:31

acolombier requested review from Swiftb0y and JoergAtGithub September 19, 2024 22:31

Swiftb0y reviewed Sep 20, 2024

View reviewed changes

JoergAtGithub requested a review from Holzhaus September 20, 2024 21:56

Holzhaus reviewed Oct 13, 2024

View reviewed changes

Swiftb0y reviewed Oct 14, 2024

View reviewed changes

src/audio/types.h Outdated Show resolved Hide resolved

src/audio/types.h Outdated Show resolved Hide resolved

src/track/beats.h Outdated Show resolved Hide resolved

acolombier mentioned this pull request Oct 14, 2024

Improve the beat marker behaviour to allow grid stretching #13768

Open

daschuer requested changes Oct 15, 2024

View reviewed changes

JoergAtGithub removed the needs review label Oct 15, 2024

acolombier force-pushed the newbeats-downbeats-rebase branch from d31af27 to 34ee683 Compare October 23, 2024 06:56

daschuer requested changes Oct 23, 2024

View reviewed changes

feat: add downbeat support to beat map

9de4d5c

Co-authored-by: Jan Holthuis <[email protected]>

acolombier force-pushed the newbeats-downbeats-rebase branch from 34ee683 to 9de4d5c Compare October 23, 2024 08:36

		// Track: \|--------------------------------------------------------\|
		// \| \| \| \| \| \|\| \| \| \|\| \| \| \|\| \| \| \| \|\|

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

Are you sure you want to change the base?

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

Conversation

acolombier commented Jun 5, 2024 • edited Loading

JoergAtGithub commented Jun 5, 2024

Swiftb0y left a comment

Choose a reason for hiding this comment

acolombier commented Jun 6, 2024

JoergAtGithub commented Jun 6, 2024

acolombier commented Jun 7, 2024 • edited Loading

JoergAtGithub commented Jun 7, 2024

JoergAtGithub commented Jun 7, 2024

acolombier commented Jun 7, 2024

JoergAtGithub commented Jun 7, 2024

acolombier commented Jun 7, 2024

acolombier commented Jun 9, 2024

acolombier commented Jun 10, 2024

JoergAtGithub commented Jun 19, 2024

JoergAtGithub commented Jun 19, 2024

acolombier commented Jun 19, 2024

acolombier commented Jun 19, 2024

Swiftb0y commented Jun 19, 2024

Swiftb0y commented Jun 19, 2024

acolombier commented Sep 19, 2024

Swiftb0y left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daschuer Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acolombier Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

ywwg commented Sep 20, 2024

JoergAtGithub commented Sep 20, 2024

acolombier commented Oct 8, 2024

Holzhaus commented Oct 8, 2024

Holzhaus left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acolombier commented Oct 13, 2024

Holzhaus commented Oct 13, 2024

acolombier commented Oct 13, 2024

Holzhaus commented Oct 13, 2024

acolombier commented Oct 14, 2024 • edited Loading

acolombier commented Oct 15, 2024

Choose a reason for hiding this comment

Holzhaus Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daschuer Oct 16, 2024 • 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

acolombier commented Oct 23, 2024

ywwg commented Oct 24, 2024

daschuer commented Oct 25, 2024

acolombier commented Jun 5, 2024 •

edited

Loading

acolombier commented Jun 7, 2024 •

edited

Loading

daschuer Oct 15, 2024 •

edited

Loading

acolombier Oct 15, 2024 •

edited

Loading

Holzhaus left a comment •

edited

Loading

acolombier commented Oct 14, 2024 •

edited

Loading

Holzhaus Oct 15, 2024 •

edited

Loading

daschuer Oct 16, 2024 •

edited

Loading