This is actually the expected behavior and I don't really see how it's major...
If we decide we don't want that, then cresc/dim needs to be removed from 2.0.3. I personally think it would be a pity but I am ready to do it if we have a consensus that it's the right thing to do.
I blame myself for filing this too late, but my hope is that there are still some traces in the MSCX code that 2.0.3 can use to distinguish the former cresc/dim lines from hairpins intended as hairpins.
I think there must be something there, and 2.0.3 just doesn't interpret it correctly. Remember, the lines become hairpins in 2.0.2—but plain hairpins, not dotted or dashed hairpins. That only happens when the file is opened with 2.0.3.
In other words, 2.0.3 makes them dashed based on some recognition that they're not just hairpins. Is there any way to reconstruct the original line instead?
2.0.3 makes them dashed because when it originally saved the file, it saved them as dashed. It's more 2.0.2's fault that it didn't show that and yet still wrote the dashed tag out, but thats of course because 2.0.2 wasn't expecting this construct. I doubt there is anything that can be done, but I'll try to look later.
To me, still not worth removing a very useful feature over.
Good thinking. The "wide dashed" line style doesn't even exist in 2.0.2, so the combination of that style and that style applying to a hairpin pretty much rules out all other possibilities.
What about the text? Is that still saved somewhere?
Make a small and simple sample file in 2.0.3, save as mscx, open in 2.0.2 and save under a different name but also as mscx and run diff against them or attach here.
We could indeed assume a dashed hairpin is a probably meant to be a text line, but what if you really *wanted* the dashed hairpin? I'd be more afriad of breaking that for regular 2.0.3 users than about this case that only affects people who work on a score in 2.0.3 then downgrade to 2.0.2, work on it more, then upgrade again.
That is why it needs a check whether it is a 2.0.2 score. If (hairpin is dashed && score is from 2.0.2 or older)
As fas as I understood 2.0.2 can't have dashed hairpins
Edit: apparently a wrong assumption, dashed hairpins are possible in 2.0.2, so automatically converting to crecendo lines won't work without potentially destroying something a 2.0.2 used legitimatly
Edit 2: hah! They do use different line styles, dashed and wide-dashed. 2.0.2 doesn't know the latter (and shows as solid), so this is the sentinel to detect a former crescendo line, in 2.0.3, when the score stems from 2.0.2
if (hairpin()->lineStyle() == Qt::CustomDashLine && score is from 2.0.2 or older)
User modified texts for them got lost though, so would need to use the Defaults for begin- and continue-text
There is no 2.0.2 older check possible, really. 2.0.3 is supposed to be 100% compatible to 2.0.2 and before. Testing for programVersion is not viable. Or we want this feature and we live with the fact that it's not 100% compatible or we remove it. Marc spoke up. Any other opinion?
The hack is clever, I could live with it even though of course we're not supposed to like hacks :-).
I wonder hat happens if we load such a score into 2.0.1 or 2.0. If they behave no worse than 2.0.2, then I guess I'll vote for the hack, with "do nothing" (live with the minor issue) being my second choice. If 2.0.1 or 2.0 refuse to load the score at all, though, then I guess maybe we should remove the feature.
I'm having them all as portable apps on a thumb drive, so I've just tested: 2.0.0, 2.0.1 and of course 2.0.2, load the 2.0.3 file just fine, and when saved the result opens fine on 2.0.3 with and without my patch
The keep/revert question was debated before, of course—mostly between you and me, Marc—and I'll be the first to admit the decision was to keep it, concluding with this: https://musescore.org/en/node/93061#comment-411391 So "document and keep" is allowable. But anything that can be done to improve the compatibility is a good thing.
Here's another idea, which could presumably use Jojo's same hack, but may be smarter as it doesn't attempt to re-create lines that may have had different text:
When 2.0.3 loads a score from 2.0.2 containing a hairpin with the wide dashed style, just turn it into a hairpin with the continuous line style. Since that's exactly what 2.0.2 would have previously done to that score, no surprises. Documenting it would be much clearer, too: "Previous 2.0.x versions do not support this feature, and will convert these lines into regular, solid hairpins." Done.
Thanks! With this one, the documentation would be "Previous 2.0.x versions do not support this feature, and will convert these lines into regular, solid hairpins. 2.0.3 can attempt to re-create the original dashed text line, but only with the default text and text properties—any changes from the defaults will be lost in this process."
It's a hack and as such, it will not always work...
* MuseScore 2.0.3, create a score with cresc line, change type of line to dash line
* Save
* Open in MuseScore 2.0.2
* Open in Musescore 2.0.3 (even with the hack, it will not look good, probably a dash hairpin...)
True. Also create a hairpin, change to wide-dashed, it'll turn into a crescendo line.
Ot misuse a crescendo line and modify for something entirely different, and that would get lost
The hack covers the common case, so should be right in some 90% or more
Comments
I think this is covered by https://musescore.org/en/developers-handbook/release-notes/release-note…
This is actually the expected behavior and I don't really see how it's major...
If we decide we don't want that, then cresc/dim needs to be removed from 2.0.3. I personally think it would be a pity but I am ready to do it if we have a consensus that it's the right thing to do.
I'd say this is documented and should stay in, so is by design.
I blame myself for filing this too late, but my hope is that there are still some traces in the MSCX code that 2.0.3 can use to distinguish the former cresc/dim lines from hairpins intended as hairpins.
I think there must be something there, and 2.0.3 just doesn't interpret it correctly. Remember, the lines become hairpins in 2.0.2—but plain hairpins, not dotted or dashed hairpins. That only happens when the file is opened with 2.0.3.
In other words, 2.0.3 makes them dashed based on some recognition that they're not just hairpins. Is there any way to reconstruct the original line instead?
2.0.3 makes them dashed because when it originally saved the file, it saved them as dashed. It's more 2.0.2's fault that it didn't show that and yet still wrote the dashed tag out, but thats of course because 2.0.2 wasn't expecting this construct. I doubt there is anything that can be done, but I'll try to look later.
To me, still not worth removing a very useful feature over.
2.0.3 could interprete the dashed hairpin from a 2.0.2 score as a Cresc./Dim. dashed line, as that is about the only Thing it could possible be?
Good thinking. The "wide dashed" line style doesn't even exist in 2.0.2, so the combination of that style and that style applying to a hairpin pretty much rules out all other possibilities.
What about the text? Is that still saved somewhere?
Make a small and simple sample file in 2.0.3, save as mscx, open in 2.0.2 and save under a different name but also as mscx and run diff against them or attach here.
We could indeed assume a dashed hairpin is a probably meant to be a text line, but what if you really *wanted* the dashed hairpin? I'd be more afriad of breaking that for regular 2.0.3 users than about this case that only affects people who work on a score in 2.0.3 then downgrade to 2.0.2, work on it more, then upgrade again.
That is why it needs a check whether it is a 2.0.2 score. If (hairpin is dashed && score is from 2.0.2 or older)
As fas as I understood 2.0.2 can't have dashed hairpins
Edit: apparently a wrong assumption, dashed hairpins are possible in 2.0.2, so automatically converting to crecendo lines won't work without potentially destroying something a 2.0.2 used legitimatly
Edit 2: hah! They do use different line styles, dashed and wide-dashed. 2.0.2 doesn't know the latter (and shows as solid), so this is the sentinel to detect a former crescendo line, in 2.0.3, when the score stems from 2.0.2
if (hairpin()->lineStyle() == Qt::CustomDashLine && score is from 2.0.2 or older)
User modified texts for them got lost though, so would need to use the Defaults for begin- and continue-text
{syntaxhighlighter }
$ diff -u cres-line-2.0.*
--- cres-line-2.0.2.mscx Thu Mar 31 15:52:12 2016
+++ cres-line-2.0.3.mscx Thu Mar 31 15:51:36 2016
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
- 2.0.2
- f51dc11
+ 2.0.3
+ f6e835e
0
@@ -111,7 +111,14 @@
0
+ 1
6
+
+ cresc.
+
+
+ (cresc.)
+
measure
{/syntaxhighlighter}
There is no 2.0.2 older check possible, really. 2.0.3 is supposed to be 100% compatible to 2.0.2 and before. Testing for programVersion is not viable. Or we want this feature and we live with the fact that it's not 100% compatible or we remove it. Marc spoke up. Any other opinion?
Yes, the comparison of versions is the difficult part.
As I said in the beginning: document (done) and keep
Hmm, not that difficult after all, but indeed quite a hack:
{syntaxhighlighter }
diff --git a/libmscore/hairpin.cpp b/libmscore/hairpin.cpp
index c07aec8..69d0319 100644
--- a/libmscore/hairpin.cpp
+++ b/libmscore/hairpin.cpp
@@ -418,6 +418,12 @@ void Hairpin::read(XmlReader& e)
if (!_continueText)
setContinueText(cresc ? "(cresc.)" : "(dim.)");
}
+
+ if (lineStyle() == Qt::CustomDashLine) {
+ QString sv = score()->mscoreVersion();
+ if (sv == "2.0.2" || sv == "2.0.1" || sv == "2.0.0")
+ _useTextLine = true;
+ }
}
//---------------------------------------------------------
{/syntaxhighlighter}
The hack is clever, I could live with it even though of course we're not supposed to like hacks :-).
I wonder hat happens if we load such a score into 2.0.1 or 2.0. If they behave no worse than 2.0.2, then I guess I'll vote for the hack, with "do nothing" (live with the minor issue) being my second choice. If 2.0.1 or 2.0 refuse to load the score at all, though, then I guess maybe we should remove the feature.
I'm having them all as portable apps on a thumb drive, so I've just tested: 2.0.0, 2.0.1 and of course 2.0.2, load the 2.0.3 file just fine, and when saved the result opens fine on 2.0.3 with and without my patch
The keep/revert question was debated before, of course—mostly between you and me, Marc—and I'll be the first to admit the decision was to keep it, concluding with this: https://musescore.org/en/node/93061#comment-411391 So "document and keep" is allowable. But anything that can be done to improve the compatibility is a good thing.
Here's another idea, which could presumably use Jojo's same hack, but may be smarter as it doesn't attempt to re-create lines that may have had different text:
When 2.0.3 loads a score from 2.0.2 containing a hairpin with the wide dashed style, just turn it into a hairpin with the continuous line style. Since that's exactly what 2.0.2 would have previously done to that score, no surprises. Documenting it would be much clearer, too: "Previous 2.0.x versions do not support this feature, and will convert these lines into regular, solid hairpins." Done.
what the heck, here we go: https://github.com/musescore/MuseScore/pull/2514
Take it of leave it, I'm fine either way ;-)
Edit, turning it into a solid line would work too:
{syntaxhighlighter }
diff --git a/libmscore/hairpin.cpp b/libmscore/hairpin.cpp
index c07aec8..17c85e3 100644
--- a/libmscore/hairpin.cpp
+++ b/libmscore/hairpin.cpp
@@ -418,6 +418,9 @@ void Hairpin::read(XmlReader& e)
if (!_continueText)
setContinueText(cresc ? "(cresc.)" : "(dim.)");
}
+
+ if (lineStyle() == Qt::CustomDashLine) {
+ QString sv = score()->mscoreVersion();
+ if (sv == "2.0.2" || sv == "2.0.1" || sv == "2.0.0")
+ setLineStyle(Qt::SolidLine);
}
//---------------------------------------------------------
{/syntaxhighlighter}
But why? It would deprive the user from detecting that a crescendo line used to be there
Thanks! With this one, the documentation would be "Previous 2.0.x versions do not support this feature, and will convert these lines into regular, solid hairpins. 2.0.3 can attempt to re-create the original dashed text line, but only with the default text and text properties—any changes from the defaults will be lost in this process."
I'm happy with either. Thanks for taking the time to work this out.
Yes, that would be the documentation, if that PR gets accepted.
Lot of criss-crossing messages there. ;-)
It's a hack and as such, it will not always work...
* MuseScore 2.0.3, create a score with cresc line, change type of line to dash line
* Save
* Open in MuseScore 2.0.2
* Open in Musescore 2.0.3 (even with the hack, it will not look good, probably a dash hairpin...)
Right?
True. Also create a hairpin, change to wide-dashed, it'll turn into a crescendo line.
Ot misuse a crescendo line and modify for something entirely different, and that would get lost
The hack covers the common case, so should be right in some 90% or more
the common case...
I will merge this in 2.0.3 branch only.
Fine by me. It is a hack after all ;-)
New PR, based on 2.0.3: https://github.com/musescore/MuseScore/pull/2516
Damn, somehow I managed to screwe up the commit message. Anyway, it is fixed in 2.0,3 now, 8ab0a85
Sweet! Thanks to all. And now, here it comes…
Automatically closed -- issue fixed for 2 weeks with no activity.