-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 and show downbeats on scrolling waveforms [vn+1] #13330
base: main
Are you sure you want to change the base?
Conversation
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 |
There was a problem hiding this 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).
// If we don't have enough space, double the capacity. | ||
if (lines.size() == lines.capacity()) { | ||
lines.reserve(lines.capacity() * 2); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: this is already done if its needed in the append afterwards. Is it feasible to do the reserve outside loop once?
if (!m_beats.isEmpty()) { | ||
QPen pen(m_beatColor); | ||
pen.setWidthF(std::max(1.0, scaleFactor())); | ||
painter->setPen(pen); | ||
painter->drawLines(m_beats); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: lets DRY this a little.
if (!m_beats.isEmpty()) { | |
QPen pen(m_beatColor); | |
pen.setWidthF(std::max(1.0, scaleFactor())); | |
painter->setPen(pen); | |
painter->drawLines(m_beats); | |
} | |
auto drawLines = [&](const auto& color, const auto& lines){ | |
if (!lines.isEmpty()) { | |
QPen pen(color); | |
pen.setWidthF(std::max(1.0, scaleFactor())); | |
painter->setPen(pen); | |
painter->drawLines(lines); | |
} | |
}; | |
drawLines(m_beatColor, m_beats); |
mixxx::UnicolorShader m_beatShader; | ||
mixxx::UnicolorShader m_downbeatShader; | ||
mixxx::UnicolorShader m_markerbeatShader; | ||
QColor m_beatColor; | ||
QColor m_downbeatColor; | ||
QColor m_markerbeatColor; | ||
VertexData m_beatVertices; | ||
VertexData m_downbeatVertices; | ||
VertexData m_markerbeatVertices; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could be simplified if instead of going through each beat and then partitioning it into downbeats, marker beats and regular beats, you "just" replaced the m_beatShader
by a mixxx::RGBShader
and just supplied the correct color for each each vertex. Does that seem feasible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's doable and sound like the way to go indeed.
This was just a quick hack to get something working to get some user testing first, before I make that better!
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. |
636a042
to
b1967d9
Compare
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 @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. |
And now I got the original again:
|
Right, my fault, The first one is related to the |
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. |
@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 🙏 |
94c256f
to
e06279c
Compare
e06279c
to
bc15b8d
Compare
It's worth to highlight the invalidation would only happen if one:
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. |
I tested again, and no asserts occured anymore!
The missing backward compatibility, was one of the main reasons, why the predecessor PRs got never merged. We need an commonly agreed strategy here. |
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 |
Great to hear!
Make sense to me. What do you think of my proposition of backward compatibility, except if the multiple bar length feature is used?
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. |
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. |
Well, the primary thing I'm confused about currently are the complications around |
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? |
There is left over from the v1 solution, which will be removed/cleaned up as part of the
Sure - the main reason for this change is, if you store the number of beats per marker, resizing marker (effectively splitting a marker in two, or merging two in one) will change the BPM. Say you have a track at 128BPM, somewhere in the track, the beat grid shift by 1/3. If you set a new marker (=divide the single marker in two), you will end up with two different BPM (slightly less than 128BPM depending of the number of beats before than new marker, slightly more than 128 after) (Note that the same usecase can be applied for tracks with a speed up or slow down, using variable BPM) IMHO, using beat length is the only way to cover every usecase and maker the user experience of editing the beat grid smoother. |
That would be great. yes.
Thank you, yes. That makes total sense. I'm very pleased with the direction this is going in, but I'm not the person that was reviewing the previous PRs, so I'd really like to know what @daschuer thinks. |
I am very happy to see progress here. Thank you for picking this ball up. I have an unfinished branch here rotting aroud since some time. The biggest issue is the pure size if this PR and the number of open topics we have discussed along these lines with valid but different concerns. My current prio is to finish the stem topic so I am afraid it will take a while for looking in all details. What we should do now is confirm the current and future data structures. In the meantime it would be nice to split out all uncritical and agreed changes so that we do not suffer from stucking again. |
I could try to split it if you think there are part that can go already and don't have any concerns.
I managed not to change the existing data structure and built the improvement on top of It would be useful if everyone with concern could give me a quick sum up of where the concerns are, so I can see if this is something my solution can address, and otherwise close that PR if it is going to a dead end. |
would it be possible to split the rendering changes from the grid editing changes? The first pass could be turned off by default and assume that the cue point is a downbeat (not always true...), but then we could make sure then rendering is right before we move on to the editing UX |
I'm going to try that next. The plan will be to break that in two PRs, one with backend changes only without edition capability, and later a PR with UI and edit feature. How does that sound? |
Co-authored-by: Jan Holthuis <[email protected]>
bc15b8d
to
693b0e4
Compare
I broke down the feature in two PR now (follow up here) and managed to reduce slighly the size. |
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:
TODO:
Fixes #13308
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.