Gsoc 2020: prepare for changes to mmrests and fix #306192 #6108

IsaacWeiss · 2020-05-22T19:59:12Z

This PR adds no new functionality and introduces no bugs,* but simply lays the groundwork so future larger changes will be easier, in keeping with the incremental process recommended in today's GSoC conference call. The upcoming changes are described in my GSoC introductory blog post: https://musescore.org/en/user/101731/blog/2020/05/17/gsoc-2020-week-2-bc-coding-repeats-rests-and-counting-overview.

Extract multimeasure rests to new class and ElementType
Rename local variables and add comments in Score::createMMRest()
Add new Style page for mmrest options

In passing, this also fixes https://musescore.org/en/node/306192.

I signed CLA
I made sure the code in the PR follows the coding rules
I made sure the code compiles on my machine
I made sure there are no unnecessary changes in the code
I made sure the title of the PR reflects the core meaning of the issue you are solving
I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
I made sure the commit message title starts with "fix #424242:" if there is a related issue
I created the test (mtest, vtest, script test) to verify the changes I made (TODO)

*Of course, I cannot guarantee this, but I think it's safe.

ecstrema · 2020-05-23T01:56:13Z

libmscore/layout.cpp

 //---------------------------------------------------------

-void Score::createMMRest(Measure* m, Measure* lm, const Fraction& len)
+void Score::createMMRest(Measure* firstMeasure, Measure* lastMeasure, const Fraction& len)


Yes thanks for verbosity! At least as useful as comments!

ecstrema · 2020-05-23T02:01:27Z

libmscore/mmrest.cpp

+      painter->setPen(pen);
+      qreal x1 = pw * .5;
+      qreal x2 = _mmWidth - x1;
+      if (_mmRestNumberPos > 0.7 && _mmRestNumberPos < 3.3) { // hack for when number encounters horizontal line


This will cause conflict with PR #6105.

Sure, if yours is merged first I will rebase.

libmscore/style.cpp

Jojo-Schmitz · 2020-05-23T08:42:59Z

Most probably needs PR #6103 being merged into master to pass the mtests on Travis.
But a simple restart of the build should show whether there a more and additional issues.

Not sure though what the vtest fails are about, @AntonioBL? Shouldn't this have been fixed with PR #6092? Or is that missing on master currently?

AntonioBL · 2020-05-23T11:49:08Z

Actually, vtest script seems to be working properly.
The problem is that, as soon as vtests start, mscore hits an assert:

convert <../mmrest-1.mscx>...
libmscore/scoreElement.h:unknown:
ASSERT: "!e || e->isMMRest()" in file libmscore/scoreElement.h, line 457

Jojo-Schmitz · 2020-05-23T11:51:58Z

Ah! So a real issue with the code.

IsaacWeiss · 2020-05-24T06:13:16Z

I guess it's file compatibility. I should have known I couldn't leave that for the end.

Jojo-Schmitz · 2020-05-24T12:19:04Z

Failures in mtests that are due to this PR, all but the guitar pro ones

Jojo-Schmitz · 2020-05-25T15:25:52Z

If you rebase now you'll see your mtest fails only, the guitar pro ones are fixed now

IsaacWeiss · 2020-05-26T23:39:30Z

Why is it erroring now? I'm not seeing what's different in the vest artifact.

Jojo-Schmitz · 2020-05-27T07:19:19Z

mtest failures, https://travis-ci.org/github/musescore/MuseScore/jobs/691524463#L4369-L4389 and https://travis-ci.org/github/musescore/MuseScore/jobs/691524463#L4409-L4940

I guess the vtest issue is the same as before

mattmcclinch · 2020-05-29T14:54:13Z

mtest/scripting/p1.log.ref needs to be updated to account for the change in the numerical value of ElementType::CHORD due to the addition of ElementType::MMREST. So wherever it says Chord (92) it should now say Chord (93). Also, I am thinking that isRest() should maybe be redefined to return true for both ElementType::REST and ElementType::MMREST, since up until now it has always returned true for multimeasure rests. This is causing problems with selection and navigation, and it is the reason for the failure of the mmrest-copy test. The other way to fix it, of course, is to make sure you always test for both isRest() and isMMRest(). This is what you have done in many places, but you have missed a few at least.

MarcSabatella · 2020-05-29T17:04:03Z

In general, any time one changes the class structure, one has to go through the source to find places where there are explicit tests against the old types and see what needs updating.

Since presumably the old isRest(0 tests were retuning true for mmrests too, one solution is to just redefine it accordingly now. Make it explicitly return true for either a rest or an mmrest. Or, define a new isRestType() that returns true for either, and change all existing isRest() calls to this excerpt where it really doesn't make sense.

Regarding the numeric values of the types, it sucks that we rely on specific values anywhere, and potentially there is an opportunity to figure out a way to make the test not depend on that any more. But it's also an opportunity to just move your new type to the end of the list, if that doesn't mess anything up (some things do depend on the actual order).

IsaacWeiss · 2020-05-31T15:51:48Z

@MarcSabatella @mattmcclinch Thank you both very much. I think the right approach is to explicitly check for isMMRest() where necessary, and not mess with redefining isRest() or switching to isRestType(). Otherwise, that would open a whole can of worms: RepeatMeasure is also a child of Rest, and isRest() doesn't currently return true for ElementType::REPEAT_MEASURE. (isChordRest() does, of course, but already in many places a set of checks for only some ChordRest subtypes is preferred.)

mattmcclinch · 2020-05-31T15:56:27Z

You opened the can of worms when you separated MMRest from Rest. I think that redefining isRest() would help close it back up.

IsaacWeiss · 2020-05-31T16:34:28Z

So is it wrong that isRest() doesn't include RepeatMeasure currently? It seems a bad idea to me to have isRest() include some subtypes but not others. It's been working just fine, and is consistent and logical, having isRest() return true for only ElementType::REST, and having isRepeatMeasure() return true for only ElementType::REPEAT_MEASURE. Sometimes isRest() is called with || isRepeatMeasure() beside it, and sometimes not, so clearly the distinction matters. But maybe it's important to put them back together.

mattmcclinch · 2020-05-31T16:42:27Z

It has caused problems in the past when an element that was known to be a ChordRest and not a Rest was assumed to be a Chord. It is a completely logical assumption, though, since ChordRest only has two direct subclasses, and in almost every other case a concrete element type does not have any subclasses of its own.

IsaacWeiss · 2020-05-31T16:46:57Z

Interesting, thanks. If I make isRest() more inclusive, is there any reason to be concerned about it returning true for a RepeatMeasure in places where it currently doesn't?

mattmcclinch · 2020-05-31T16:55:26Z

I would be hesitant to make isRest() return true for RepeatMeasure, since currently it does not. RepeatMeasure is weird in that although it is a subclass of Rest, the real-world entity is not any kind of rest at all.

MarcSabatella · 2020-05-31T17:08:57Z

I see this as an opportunity to clean some of these kinds of things up. That could totally mean changing the class hierarchy so RepeatMeasure is not in fact a subclass of Rest at all, for example. This could perhaps be coordinated with @Kartikay26 's project.

IsaacWeiss · 2020-05-31T20:43:54Z

So I half expected there might be bugs fixed or prevented as a side benefit of distinguishing the classes. I've just come across at least one concrete example where it is problematic for isRest() to return true on mmrests, as it does currently, and my changes unintentionally fixed it: distinguishing the types means you get the right result when trying to enter lyrics on an mmrest, whereas bad things happen in 3.4.2 and 3.5-alpha.

So far, I've gone through about half of the calls to isRest(), and in almost none does it make sense to include mmrests (lots of stuff about laying out dots, for instance). If those wiser than me think it is important to use an isRestType() in those few circumstances, I will.

IsaacWeiss · 2020-06-01T19:25:27Z

"apt-get install failed"? What did I do now?

mattmcclinch · 2020-06-01T19:27:40Z

Push again and hope for the best. Sometimes this kind of thing happens, and it has nothing to do with anything you did; it is just Travis being temperamental.

IsaacWeiss · 2020-06-01T20:20:21Z

Woohoo, all checks passed!

IsaacWeiss · 2020-06-01T20:55:22Z

Changed commit message to reference fixing https://musescore.org/en/node/306192. Should be ready to merge.

libmscore/edit.cpp

mscore/editstyle.ui

IsaacWeiss · 2020-06-02T23:27:21Z

Not going to try implementing the mmrest Inspector again yet. I may adjust my project schedule to try learning QML towards the end, but if not, multimeasure rests are just one among the other elements that don't have Inspectors yet.

Add class MMRest and ElementType::MMREST (fix #306192: Lyrics entry with multimeasure rest selected) Add new Style page Rename local variables and add comments in createMMRest()

mattmcclinch · 2020-06-04T02:45:18Z

You are going to want to fetch the latest changes to the master branch and rebase. There should not be any conflicts, but that should allow the checks to pass. As for the inspector, you might want to take a look at mattmcclinch@b956c5f. There is currently no glyph for multimeasure rests in the icon font, so I have it show a question mark for now.

IsaacWeiss · 2020-06-04T03:23:57Z

@mattmcclinch, you are a superhero. And you're just another volunteer?

mattmcclinch · 2020-06-04T03:46:13Z

Yup, just another volunteer. And I am only too happy to help.

IsaacWeiss · 2020-06-04T05:18:17Z

Superseded by the much more complete #6161.

IsaacWeiss changed the title ~~Gsoc 2020 mmrest class~~ Gsoc 2020: prepare for changes to mmrests May 22, 2020

ecstrema reviewed May 23, 2020

View reviewed changes

libmscore/style.cpp Outdated Show resolved Hide resolved

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch from 5696b73 to 0b0d306 Compare May 24, 2020 06:14

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch from 0b0d306 to 66f71ff Compare May 26, 2020 23:00

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch 4 times, most recently from 24ffbd7 to 31e43cb Compare May 28, 2020 20:39

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch from 31e43cb to 3c3f135 Compare June 1, 2020 18:33

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch from 3c3f135 to 1862c70 Compare June 1, 2020 19:32

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch from 1862c70 to 025b799 Compare June 1, 2020 20:49

IsaacWeiss changed the title ~~Gsoc 2020: prepare for changes to mmrests~~ Gsoc 2020: prepare for changes to mmrests and fix #306192 Jun 1, 2020

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch from 025b799 to 8bdde31 Compare June 1, 2020 21:20

Jojo-Schmitz reviewed Jun 2, 2020

View reviewed changes

libmscore/edit.cpp Outdated Show resolved Hide resolved

Jojo-Schmitz reviewed Jun 2, 2020

View reviewed changes

mscore/editstyle.ui Outdated Show resolved Hide resolved

Prepare for changes to multimeasure rests

8087803

Add class MMRest and ElementType::MMREST (fix #306192: Lyrics entry with multimeasure rest selected) Add new Style page Rename local variables and add comments in createMMRest()

IsaacWeiss force-pushed the gsoc-2020-mmrest-class branch from 8bdde31 to 8087803 Compare June 2, 2020 23:34

IsaacWeiss mentioned this pull request Jun 4, 2020

GSoC 2020 Milestone 1: add style options for H-bar multimeasure rests #6161

Closed

8 tasks

IsaacWeiss closed this Jun 4, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Gsoc 2020: prepare for changes to mmrests and fix #306192 #6108

Gsoc 2020: prepare for changes to mmrests and fix #306192 #6108

IsaacWeiss commented May 22, 2020 •

edited

Loading

ecstrema May 23, 2020

ecstrema May 23, 2020 •

edited

Loading

IsaacWeiss May 24, 2020

Jojo-Schmitz commented May 23, 2020 •

edited

Loading

AntonioBL commented May 23, 2020

Jojo-Schmitz commented May 23, 2020

IsaacWeiss commented May 24, 2020

Jojo-Schmitz commented May 24, 2020 •

edited

Loading

Jojo-Schmitz commented May 25, 2020

IsaacWeiss commented May 26, 2020

Jojo-Schmitz commented May 27, 2020 •

edited

Loading

mattmcclinch commented May 29, 2020

MarcSabatella commented May 29, 2020

IsaacWeiss commented May 31, 2020 •

edited

Loading

mattmcclinch commented May 31, 2020

IsaacWeiss commented May 31, 2020

mattmcclinch commented May 31, 2020 •

edited

Loading

IsaacWeiss commented May 31, 2020

mattmcclinch commented May 31, 2020

MarcSabatella commented May 31, 2020

IsaacWeiss commented May 31, 2020

IsaacWeiss commented Jun 1, 2020

mattmcclinch commented Jun 1, 2020 •

edited

Loading

IsaacWeiss commented Jun 1, 2020

IsaacWeiss commented Jun 1, 2020

IsaacWeiss commented Jun 2, 2020

mattmcclinch commented Jun 4, 2020

IsaacWeiss commented Jun 4, 2020

mattmcclinch commented Jun 4, 2020

IsaacWeiss commented Jun 4, 2020

Gsoc 2020: prepare for changes to mmrests and fix #306192 #6108

Gsoc 2020: prepare for changes to mmrests and fix #306192 #6108

Conversation

IsaacWeiss commented May 22, 2020 • edited Loading

ecstrema May 23, 2020

Choose a reason for hiding this comment

ecstrema May 23, 2020 • edited Loading

Choose a reason for hiding this comment

IsaacWeiss May 24, 2020

Choose a reason for hiding this comment

Jojo-Schmitz commented May 23, 2020 • edited Loading

AntonioBL commented May 23, 2020

Jojo-Schmitz commented May 23, 2020

IsaacWeiss commented May 24, 2020

Jojo-Schmitz commented May 24, 2020 • edited Loading

Jojo-Schmitz commented May 25, 2020

IsaacWeiss commented May 26, 2020

Jojo-Schmitz commented May 27, 2020 • edited Loading

mattmcclinch commented May 29, 2020

MarcSabatella commented May 29, 2020

IsaacWeiss commented May 31, 2020 • edited Loading

mattmcclinch commented May 31, 2020

IsaacWeiss commented May 31, 2020

mattmcclinch commented May 31, 2020 • edited Loading

IsaacWeiss commented May 31, 2020

mattmcclinch commented May 31, 2020

MarcSabatella commented May 31, 2020

IsaacWeiss commented May 31, 2020

IsaacWeiss commented Jun 1, 2020

mattmcclinch commented Jun 1, 2020 • edited Loading

IsaacWeiss commented Jun 1, 2020

IsaacWeiss commented Jun 1, 2020

IsaacWeiss commented Jun 2, 2020

mattmcclinch commented Jun 4, 2020

IsaacWeiss commented Jun 4, 2020

mattmcclinch commented Jun 4, 2020

IsaacWeiss commented Jun 4, 2020

IsaacWeiss commented May 22, 2020 •

edited

Loading

ecstrema May 23, 2020 •

edited

Loading

Jojo-Schmitz commented May 23, 2020 •

edited

Loading

Jojo-Schmitz commented May 24, 2020 •

edited

Loading

Jojo-Schmitz commented May 27, 2020 •

edited

Loading

IsaacWeiss commented May 31, 2020 •

edited

Loading

mattmcclinch commented May 31, 2020 •

edited

Loading

mattmcclinch commented Jun 1, 2020 •

edited

Loading