Cresc./Dim. dashed line from 2.0.3, rendered as hairpin in 2.0.2, gets converted into dotted hairpin when loaded back into 2.0.3

• Mar 31, 2016 - 04:35
S3 - Major

Cresc./Dim. dashed lines from 2.0.3, rendered as hairpins in 2.0.2, get converted into dotted hairpins when loaded back into 2.0.3.

in 2.0.3, becomes
in 2.0.2, and then
back in 2.0.3.

If this is insurmountable, please close this issue and we'll hope nobody runs into this problem.


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.

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

@@ -111,7 +111,14 @@

+ 1
+ cresc.
+ (cresc.)


Attachment Size
cres-line-2.0.3.mscx 4.13 KB
cres-line-2.0.2.mscx 3.93 KB

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?

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;
+ }


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: 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.

Status (old) active patch (code needs review)

what the heck, here we go:

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);


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."

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