Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beats: Add editing controls for bar annotations #13330

Closed

Conversation

acolombier
Copy link
Member

@acolombier acolombier commented Jun 5, 2024

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

image

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
Copy link
Member

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

Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 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
Copy link
Member Author

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.

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

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

@acolombier
Copy link
Member Author

acolombier commented Jun 7, 2024

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
Copy link
Member

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

grafik
grafik

@JoergAtGithub
Copy link
Member

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.

grafik
grafik
grafik
grafik

@acolombier
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

Fixed

@acolombier
Copy link
Member Author

@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 🙏

@acolombier acolombier force-pushed the newbeats-downbeats-rebase branch 2 times, most recently from 94c256f to e06279c Compare June 9, 2024 15:24
src/track/beats.cpp Outdated Show resolved Hide resolved
@acolombier acolombier force-pushed the newbeats-downbeats-rebase branch from e06279c to bc15b8d Compare June 9, 2024 16:39
@acolombier
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

I took the freedom to amend the changes directly to the commit.

I was bugged the most by these padding beats.
Fractional beats that can be easily created because the degree of freedom the user has with the controls.

Captured that in the issue so we don't block that PR

@ywwg
Copy link
Member

ywwg commented Oct 28, 2024

@daschuer I think our long-term project experience of PRs of this kind is that it is unfortunately not possible to fix all the issues in large PRs before merge. This is one reason I try to insist on smaller PRs but that doesn't happen for a variety of reasons. After seeing this play out many times, I think the best approach may be to get it to "good enough" state and merge, then do fixes in whatever necessary followups. I do not love this mode of development and it leads to regressions, but after 15 years of working on mixxx I have seen more harm from developers getting frustrated than I have from bad code landing in the tree.

I think it will also help if you better explain which of your notes are blocking vs which ones are not. Then we can go through and know exactly which issues are most important. My observation is often you make notes on PRs that are notes for the future and the author thinks it is a blocking comment. So if you can be explicit about this it will help make things easier. Do you think you can mark up your comments with this status by wednesday?

@daschuer daschuer changed the title Beats: Add editing controls and show downbeats on scrolling waveforms [vn+1] Beats: Add editing controls for bar anotations Oct 28, 2024
@daschuer daschuer changed the title Beats: Add editing controls for bar anotations Beats: Add editing controls for bar annotations Oct 28, 2024
Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have spotted some more issues. (sorry)

I like also finish my testing with the visuals before merge.

if (isDoubleBeat(beatPositions, i) && isBeatCounting) {
isBeatCounting = false;
beatsPerBar = static_cast<mixxx::audio::BeatsPerBar>(
std::lround((std::floor(position - markerPosition) /
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using floor here is unnecessary. We must not use the long type in Mixxx, because it has different size on different targets. Position is audio::FramePos which is a double.

Suggested change
std::lround((std::floor(position - markerPosition) /
std::round((position - markerPosition) /

isBeatCounting = false;
beatsPerBar = static_cast<mixxx::audio::BeatsPerBar>(
std::lround((std::floor(position - markerPosition) /
previousBeatLengthFrames)));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can previousBeatLengthFrames be 0? Than we have diff by zero.

return nullptr;
}
auto position = beatPositions[i];
audio::FrameDiff_t beatLengthFrames = position - previousPosition;
// If the current beat is a "closing" double beat
if (isDoubleBeat(beatPositions, i) && isBeatCounting) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does assume that a beat_change_marker = double beat is a down beat, right?

We have discussed above, that the beat_change_maker can also be used to mark beat changes within a bar.
Since I consider this an exceptional use case this is OK for me to have than an incorrect beats per bar value.

However than it does not require a warning below.

if (!beatsPerBar.isValid()) {
qWarning() << "Invalid bar definition found in the BeatMap:"
<< beatsPerBar << "- Ignoring";
beatsPerBar = kDefaultBeatsPerBar;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather keep here the invalid BeatsPerBar state. We can than consider indvidual set beats using beat_change_makers have no BeatsPerBar value = invalid.
The alternative would be using one.

}

bool isDoubleBeat(const QVector<audio::FramePos>& beatPositions, int beatIdx) {
if (beatIdx <= 0 || beatIdx > beatPositions.size()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (beatIdx <= 0 || beatIdx > beatPositions.size()) {
if (beatIdx <= 0 || beatIdx >= beatPositions.size()) {

@acolombier
Copy link
Member Author

I'm about to restart efforts to get this over the line. Just would like to confirm where are currently the vetos on:

  • Newly introduced std::optional<std::shared_ptr<>> should use only std::shared_ptr<>. No refactor of the existing one required.
  • New beat marker only set existing beat to maker (must have) if quantize is on (nice to have)

Beat grid shift shouldn't be a blocker and I'm hoping my last explanation of the current behaviour will help lifting this one.

@daschuer could you confirm this please?

@daschuer
Copy link
Member

  • Replace std::optional<std::shared_ptr<>> ✔️

I don't understand stand the second point.

My outer requirement is to not introduce unwanted padding beats.

Once this is merged people will start using it, and may mess up the beat grid with padding beats. Let's go the safe route and not allow this here. Since this is anyway an intermediate step, we can iterate from there after gaining some experience in the alpha state.
This topic is well described in:
#13768 (comment)

@acolombier
Copy link
Member Author

acolombier commented Nov 20, 2024

I don't understand stand the second point.

This is my trying to summarize #13330 (comment) and making sure I understood your issue well. Basically what i'm saying, it don't make padding, except if quantize is on.

My outer requirement is to not introduce unwanted padding beats.

Yes, unwanted == quantize=on. Are we okay with that?

This would mean, with quantize=on, we would:

  • Have set_marker to only change the neared beat to a marker
  • translate will translate all the grids

with quantize=off, we would:

  • Have set_marker make a marker beat at the current playpos
  • translate will translate the local grid (the one where playpos is currently in)

Do we have an agreement? Padding beats are my must have since this is the core of #13308

@daschuer
Copy link
Member

I am sure we want the same final result since I can very much confirm #13308.
This is also the essence we have discussed in #13768 and what is implemented in Repsyps. Hover allowing padding beats is IMHO a strong misconception. They almost never happen in real music, so it should not happen every time we add a new beat-grid in Mixxx.

Using Quantize, does probably not work well for "us". I say "us" because we have discussed to follow the "Respsys" approach and this has been dismissed because it does not allow to point to beats. With Quantize=On we can also not point to a beat, which makes the common GUI for the Quantize on/off approach hard to use/understand.

We may decide to follow Respsys 1:1 though and revise our decision.

Did you hat a chance to look at it. What are your pros and cons?

What is the use case? Please confirm.

We have discussed this alternative workflow:

Lets imagine, you have an aligned beat grid in the first part of the track. You notice that at the end of the track the beats are no longer aligned. You seek through the track and find a first beat that is off. You cue the track to that beat by ears. And press "a button".

Are we aligned with that?

My Idea of the implementation is:

Mixxx will automatically place a beat-change-marker at the previous down-beat, and adopt the new tempo from the distance between the placed beat and the beat-change-marker. It shall be close to the old beat, so maybe it is required to place a number of beats in between to not create insane low tempos.

After that you can adjust the tempo of the new beat grid to cover a long new region as long as possible. Slight tempo/onset variations are typical if different instruments are used or when played live. (Quantize can here be used to snap to a detected onset in that region. See #2917)

The shift-beat feature is useful by now, if the analyses has not picked the exact onset of the beat. You may adjust the whole track.

Shifting a region between two other regions does not work because it will create two padding beats. This may be desired when a region is played with an instrument with a delayed onset. For syncing this means the follower track will speed up and slow down quite fast at that point which creates an unwanted yowling. This situation must be avoided.
Musically such an instrument is still in tempo but actually delayed. In the same way as in a overall constant track you need to find a compromise for the onsets of all devices. For this, the shift feature has to shift all beats of all beat grids in the deck even across tempo changes.

If this is still not possible you may create a phrase sized region with a slightly slower tempo. This avoids jouling in the follower track, because the tempo change is minimized.
If you really want the padding beat, because vocalist has mist their cue or such. You can explicit add a one-beat beat grid.

Does this match you approach?

@acolombier
Copy link
Member Author

Hover allowing padding beats is IMHO a strong misconception

I think we have a fundamental disagreement here.

Once again, I'm finding myself quite frustrated to see the essence of this PR being completely tore down after 5 months of effort and approval from the rest of the team.

I appreciate you are approaching the problem from a more scientific aspect, thinking with music theory at heart, while I went for a more practical and UX oriented approach. For example:

If you really want the padding beat, because vocalist has mist their cue or such. You can explicit add a one-beat beat grid

As I'm sure you tried (since Jan's PR was already following the approach your are suggesting), doing this will change the BPM temporarily. Say you need to pad 1/5 on a 130 BPM track, you end up temporarily setting up the track tempo to 650 BPM. So as you are syncing with another track, this other track suddenly see its BPM multiplied by 5 and end up off by one beat.

With this current approach, both track stay in BPM sync, with the second deck slightly slowed down to stay in sync with the track, and still align on phase.

Beside all the respect and admiration I have for you and your dedication to the project, I am now pretty sure we are not going to agree and will likely both continuing to defend our approach with endless back'n'forth messages.

Can you see a trade-off to be found in line with my proposal above, which does not:

  1. Drop the padding beat entirely
  2. Require to fundamentally restart the work from zero (or near)

If not, I suggest we pause the work and resolve that in the monthly December meeting, so we can quickly get a consensus.

@daschuer
Copy link
Member

daschuer commented Nov 21, 2024

The frustration happens on both ends ... but as allways and especially after our latest discussion with other topic, I am willing to find a compromise. This requires a good understanding for each other. Let's not repeat the issue here and find this common understanding first.

In my post above I have raised two questions, they are assential for me to find a compromize. Can you please egive a short answer:

  • Did you watch the Respsys tutorial? What is the major downside for you of this approch?
  • Did I describe the use case corretcly?
  • What does not work with the desribed approach for you?

Serato does also not allow padding beats by default. See this video:
https://www.youtube.com/watch?v=9H7tlPJwrtQ

When you set a new beat-marker, the tempo of the region before and after is adjusted. You can even see that a slight change in the already propper aligned initial section when the tutor is placing the first beat change marker, without he noticed/mentioned int. This is the downside of this approach.

You have alread stated that you don't whant that. Correct?

This solution would be OK for me as an itermediate state to merge this PR, though.


Can you see a trade-off to be found in line with #13330 (comment) above, which does not:

Yes, I can aknowledge it.

Here my comments:

  • My Idea is to use the quantize button to quantize a newly set beat marker to the detected on-sets, or any other auto-detected defaults.
  • the roposed quantize=on mode matches the approch in the Serato tutorial along with the downsides of messing up the previous section.
  • Two modes for a single button are hard to use. It is better to have that explicit on a button.

Require to fundamentally restart the work from zero (or near)

This probabyl is sourced by a missanderstanding. Because I consider the majority of this PR as well done. Using the two modes with quantize as proposed increase the complexity even more.

It would be easy to add another beat-change-marker at the begginning of the padding beat. A peading beat is a change, so a marke at this place is consistent.

It is more work is to introduce the mode I have described. But the most work is probably to compare the models we found in the wild and pick the best for Mixxx. My idea is that we use "only" the change marker at the at the begining of the original padding beat and calculate the new bpm form the resulting distance.

We can one by one add in follow up PRs helper that snap to reasonable values and such, to ease up the work for users. This all fits to the model of "no padding beat".

@daschuer
Copy link
Member

This is another Serato one, showing how to annotatte changing tempos on the fly by tapping the down beat:
https://www.youtube.com/watch?v=edqBHvSkNOs
This would not be possible with padding beats.

@acolombier
Copy link
Member Author

* Did you watch the Respsys tutorial? What is the major downside for you of this approch?

I did. The major downside is how much additional feature and UX work will be needed to achieve sufficiently of this implementation and make it usable by user. This is what I meant by Require to fundamentally restart

* What does not work with the desribed approach for you?

The implicit change of BPM, as explained in intro

Serato does also not allow padding beats by default.

Traktor Pro does.

It is better to have that explicit on a button.

Happy with that. This is #13768 was about (adding the a "non-padding" CO, since I had already implemented the other approach). In order to limit the effort on this PR and iterate on the feature, I could reserve beats_set_change_marker for the non padding marker, and user something like beats_set_new_marker for the currently implemented appraoch, or also use beats_set_change_marker's value (1 = reserved for non padding marker/BPM scale, 2 = new grid with padding marker). Does that sound fine?

My idea is that we use "only" the change marker at the at the begining of the original padding beat and calculate the new bpm form the resulting distance.

This leads to the limitation stated above tho.

this will change the BPM temporarily. Say you need to pad 1/5 on a 130 BPM track (e.g live version, with some "human imperfection"), you end up temporarily setting up the track tempo to 650 BPM. So if you are playing in sync with another track, this other track suddenly see its BPM multiplied by 5 and end up off by one beat. (Since the padding was here translating of an "Human delay", and not a beat)

With this current approach [padding beat], both track stay in BPM sync, with the second deck slightly slowed down [one beat will be scaled to 1+1/5 of the first deck] to stay in sync with the track, and still align on phase.

We can one by one add in follow up PRs helper that snap to reasonable values and such, to ease up the work for users.

I'm glad to see we are in synch with this. This is already the approach taken with the UI.

I just would to wrap up here to highlight that in the current state, none of the Serato usecase are blocker with the current approach, as Jan demonstrated here. Yes, it requires you to explicitly "acknowledge" the BPM change (which I explicitly didn't like on the Serato-like approach you are suggesting). This is why we talk about adding another CO next which would auto scale the grid, and this impact the BPM of the grid previous to the play position and translate the grid after (or scale it if it is already a defined grid?)

@daschuer
Copy link
Member

daschuer commented Nov 21, 2024

Dealing with the padding beat without annotation as beat change will complicate the whole thing a lot.
Can we agree to set two beat-change-markers for this case?

which I explicitly didn't like on the Serato-like approach you are suggesting.

I do not suggest the Serato approach. I also don't like the changing temp on the left. However if you are in the progress of editing the right site anyway we can effort the tempo change, which a new beat position actually is.

@daschuer
Copy link
Member

Interesting summary how other tools do it:
https://pestrela.github.io/dj_kb/traktor_elastic_beatgrids/

@acolombier
Copy link
Member Author

Dealing with the padding beat without annotation as beat change will complicate the whole thing a lot.
Can we agree to set two beat-change-markers for this case?

I'm struggling to see how this would complicate the whole thing. From what I can see, it is actually to opposite, and having to create an "end marker" or a "padding area" (that is, with a start and a stop) explicitly sounds like the complicating approach

However if you are in the progress of editing the right site anyway we can effort the tempo change, which a new beat position actually is.

Here you are taking the assumption that it is fine to "mess up" the right grid, since the user would have not proceed it yet. What if this is not true and we already have an explicitly set marker both on left and right? Shifting would be wrong, since it was likely set at the right place, and scaling would be wrong since it was likely already defined correctly.

Interesting summary how other tools do it:
https://pestrela.github.io/dj_kb/traktor_elastic_beatgrids/

Indeed. Traktor 3's lack of multiple BPM is a real pain for sure, but its habitability to pad without mutating other grid sections (BPM and position) is really something I got used to and I cannot believe I would be the only one.
Perhaps, like for the cue, we should have setting for the grid edition? This means we could merge this PR as the Traktor-like policy implementation, and other contributor could implement other policies in the future?

@daschuer
Copy link
Member

Traktor Pro 4 has also eleminated the padding beats by changing the tempo of the left zone: https://www.youtube.com/watch?v=l2Rn6dMG0dI

@acolombier
Copy link
Member Author

Great to hear.

This means we could merge this PR as the Traktor-like policy implementation

I guess this should be Traktor3-like then.

@acolombier
Copy link
Member Author

@mixxxdj/developers it would be great if you could give some feedback on whether you also think padding beats are a deal breaker?

@mixxxdj mixxxdj deleted a comment from acolombier Nov 23, 2024
@mixxxdj mixxxdj deleted a comment from daschuer Nov 23, 2024
@acolombier
Copy link
Member Author

Not interested to work on this anymore

@acolombier acolombier closed this Dec 13, 2024
@khimaros
Copy link

@acolombier thank you for all of your effort in this. i'm sad to see all of this cumulative work abandoned (again), because this is such a fundamental feature. what is the process for starting a "developers" vote on this PR as mentioned earlier?

@ronso0
Copy link
Member

ronso0 commented Dec 14, 2024

@khimaros There is no such process, after all it needs a dev with the motivation and skills.
Anyone can pick up an abandoned branch (as long it's not been deleted) and continue the work.

@acolombier
Copy link
Member Author

acolombier commented Dec 14, 2024

thank you for all of your effort in this

Appreciate your support @khimaros

what is the process for starting a "developers" vote on this PR as mentioned earlier?

There is no such process

We do have a process, which may be run either internally or publicly on Zulip. It's still quite experimental, but in the current case it did not bare any fruits and no consensus could be found.
It's not to say that this will eventually reach an agreement, but for now I have lost motivations to carry this forward.

@ronso0
Copy link
Member

ronso0 commented Dec 14, 2024

I interpreted the question about "the process" rather about if/how we vote to force-revive a PR.

@nitzanbueno
Copy link

Would you mind summarizing what's already done and what's missing to merge this PR for future developers who want to carry it to the finish line?
Just the MVP to merge, no extra features and such.

@acolombier
Copy link
Member Author

This was meant to be an MVP, but the core design didn't get consensus. I would suggest any devs interested in this feature to pick this work off #12343

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multiple beat grid on a single track
9 participants