Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Beats: Add editing controls for bar annotations #13330
Changes from all commits
4b4892e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This is not understandable without looking up the implementation which is out of sight here.
auto is here
std::optional<BeatsPointer>
=std::optional<std::shared_ptr<const Beats>>
std::shared_ptr
is already optional. So wrapping it into a std::optional is redundant.Currently the pointer nature is hidden, which may lead to missing null checks.
With this construct we have to deal with nullptr and nullopt.
In case
trySetBeats()
returns nullptr, the beats are deleted from the track. I don't think this is the desired behaviour here. So let's just remove the optional wrapper.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.
What you are suggesting make sense.
I looked into it in the span of that change is wide, since this
std::optional
is already used in the Beat API. I will add an issue to capture your thought and allow us to fix that going forward.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.
#13806
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.
It is OK for me to only alter the code in this PR. Changing the other is also welcome of cause.
I consider this a merge blocker.
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.
This behaves cumbersome now. What is the use case once you have set a change maker?
Probably moving the change marker with all the following beats. However, I am in doubt that the previous bar region is kept unchanged and a padding bar is created. So we may either change the tempo of the previous region, or move them as well.
In general I think these padding beats are a pain. There is no good approach to get rid of them once created.
So I think Mixxx should not allow to create them in the first place.
If a use rally wants them, they can add two change markers
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 strongly disagree; Beatgrids are meant to be contained. If you create a new one, it makes sense to inherit the previous one's BPM, but if you adjust the BPM of it, it should not affect any other adjacent grids. When it comes to BPM.
When it comes to global BPM adjustment, this is an existing limitation of non-const tempo AFAIK, so we may consider a new feature, but clearly out of scope for this PR.
I don't think padding bar are necessary any more with the beatgrid reword introduced by this PR
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.
Clarification on this is a relase blocker.
Confirmed. This means to me that the region before the beat change marker shall not change.
The issue is here that it does change the last bar of the previous region, introduceing a highly undesired padding beat by default.
To find a suitable solution, we need to consider the use case.
It is easy possible in case we have only one bea like before.
In case the user has adjusted the tempo in some regions, it is likely that the whole track is still affected. So it still should be applied to the whole track.
What other use cases we have?
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.
Since you define beatgrid by their start and not their end, it made sense to me to keep the start as immutable. This means that if you shift a beatgrid, the start will move (and thus change the end of the previous grid), but the end will be inferred from the next grid.
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 don't think we have a use case for this. This will only mess up the beat grid.
These padding beats don't have a counterpart in the music theory, are undesirable in the sync case and Hart to fix once created. Let's avoid them unless the user explicit wants them.
Or do I miss a case?
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.