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

refactor beam code #9792

Merged
merged 1 commit into from
Nov 25, 2021
Merged

refactor beam code #9792

merged 1 commit into from
Nov 25, 2021

Conversation

Nick-Mazuk
Copy link
Contributor

Resolves: #9023, #9494

Screen Shot 2021-11-18 at 9 22 55 PM

This PR is a complete rewrite of the beaming code to match with @oktophonie's new beam specifications. This PR should receive his approval before merging.

Attached are a PDF of the desired results I used for testing as well as the original MuseScore file that generated those results.

beams.pdf

stems.mscz.zip

There are a few features that used to work in the old beaming code but are not yet implemented yet. Expect these in a new PR very soon:

  • Respecting all style preferences
  • Cross-staff beams
  • Beam breaks
  • Feathered beams

As far as I know, the missing features do not produce crashes or other unintended side effects. Instead of waiting to submit this PR until those features are done, I'm submitting it to:

  • Gather feedback earlier. This code was written from scratch, and while I did my best to eliminate all possible bugs, the lack of solid unit and integration testing made it difficult to guarantee it's free of bugs. So the more people that use it and report bugs, the better the beaming code will be before the alpha launch.
  • Limit potential merge conflicts. This is a long-lived branch, and those can make collaboration difficult. As long as I'm working on the beam code in a long-lived branch, others cannot make edits or fix bugs. By submitting this PR before everything is done, it gives others the freedom to fix bugs and to use the new APIs freely (granted there are fewer public APIs).

@Nick-Mazuk
Copy link
Contributor Author

I'll look at the failed test tomorrow

@MarcSabatella
Copy link
Contributor

I just want to say, I am really happy to see this happening!

The cross-staff beaming is a pain currently because it can't laid out fully until we calculate system distances, but we can't do that until we do "most" beaming, so there are all sorts of dependencies and obscure bugs and glitches that result. Similar story for cross-measure beams, and most especially ones that cross systems. Would be great to be able to finally handle those, but even if this doesn't do the job right away, a major rewrite of the beam code was oong overdue, and hopefully it's a good first step to solving those other thorny problems.

@RobFog
Copy link

RobFog commented Nov 22, 2021

Rebase needed.

@Nick-Mazuk
Copy link
Contributor Author

Pushed an update with a rebase and hopefully fixed the unit tests to match the new specs.

Admittedly, I did remove a few outdated unit tests and I do need to add many more unit tests in future PRs.

fix compile errors from rebasing

fix codestyle

fix beam positions with non-standard noteheads

fix end of flag

fix codestyle

fix tests checkpoint

minor change

test savepoint

remove outdated beam tests

update codestyle

fixed style property type value

update style preference value from int to double

fix type errors when accessing style values

fix all tests with beams
@Nick-Mazuk
Copy link
Contributor Author

The vtests are failing, but I'd expect them to fail given that this PR includes substantial visual changes.

@oktophonie oktophonie added the vtests This PR produces approved changes to vtest results label Nov 25, 2021
@wizofaus
Copy link
Contributor

wizofaus commented Dec 2, 2021

It would seem that this has broken the case where the user has manually adjusted the beam position (in which case the y positions are stored in a the property 'fragments', but then in layout2( ) this just gets overwritten? @Nick-Mazuk


int fragmentIndex = (_direction == Direction::AUTO || _direction == Direction::DOWN) ? 0 : 1;
fragments[frag]->py1[fragmentIndex] = startAnchor.y();
fragments[frag]->py2[fragmentIndex] = endAnchor.y();
Copy link
Contributor

Choose a reason for hiding this comment

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

I would think we need to check the _userModified flag at this point, and not overwrite y y coordinates for fragments where that's true? @Nick-Mazuk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
vtests This PR produces approved changes to vtest results
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[MU4 Issue] Rationalise stem shortening outside of stave
6 participants