MuseScore 2/3 Compatibility
Since I see there has been discussion of this here, I want add my comments on the side of those who find the lack of compatibility between MuseScore 2 and MuseScore 3 a major problem. It is a problem especially for me because 1) I have a very substantial library of MuseScore 2 scores, and 2) it is part of my style as a composer that I am continually generating new compositions by revising or combining old ones.
As an example of the problems, I selected a random MuseScore 2 score, opened it in both MuseScore 2 and Musescore 3, and saved the results, attached. I answered No to the reset question in MS3 for the attached score, but I also opened the same MS2 score in MS3 answering Yes, and on casual inspection I don't see any difference between the Reset No and Reset Yes MS3 versions, Just to name the problems I immediately noticed:
- In the MS 3 version the formatting of the lead page has been distorted.
- In the MS3 score the measure widths have been greatly increased, resulting in bizarrely isolated lyrics syllables, and what is worse, increasing the number of pages in the score from 10 to 16. I spent a lot of care in this score trying to minimize the number of page turns, but the MS3 score now has many more of them. If it were ever performed, the audience would probably wonder if all the paper rustling was supposed to be some avant-garde part of the music.
- In some measures, e.g. measure 19, the MS3 version has turned a single hyphen in the lyrics to a double hyphen.
- The rall. extension at the end are distorted in the MS3 version.
I don't find this a minor problem because 1) I am going to be revising and reworking old MS continually so I will always be having to deal with these alterations, and 2) the alterations mean the converted score may have distortions that even meticulous proofreading may miss.
This is a choral score, and I suspect other sorts of scores may exhibit different problems in converting. But my point is that the lack of reliable and complete backward compatibility between MS2 and MS3 is likely to double or triple the amount of time and effort I'll need to spend on future versions of my work, if I want to use MS3 for them.
I'd say the developers of MuseScore 3 were too narrowly focused on the assumption that almost everyone uses MuseScore to compose scores from scratch, and underestimated how common it is for users to use MuseScore to create new scores based on previous ones.
The only thing I can suggest for MuseScore developers is that they keep MS2 available for the indefinite future, or maybe at least until they have a future version of MuseScore which has backward compatibility with MS2.
| Attachment | Size |
|---|---|
| MS3EXAMPLE_Reset_no.mscz | 114.53 KB |
| MS2EXAMPLE.mscz | 113.86 KB |
Comments
I can't imagine how MsueScore 2 would ever cease to be available in some form; the Internet has a long memory. But it will really only be an issue for existing users, who already have it, so continuing to make it available ourselves is probably not all that important. And on the contrary, we don't only assume people create scores from scratch; but those who wish to revisit older scores can continue to use MsueScore 2, or spend the few minutes it might take to update them.
Anyhow, regarding your example:
Yes, manually adjusted text on title pages will be an issue if you take the reset, but also takes but seconds to fix, so I still recommend it in general. But your measures are indeed much wider in MsueScore 3, and I'm not sure why. I take it you didn't submit a bug report on this during the beta? Would be worth doing so now. I can see you have set the measure spacing to 1.5sp in Format / Style / Measure, and that's a very wide setting, maybe it was to work around some deficiency in 2.x, but simply returning that to its default of 1.2 produces much better results. You should also reduce the lyrics bottom distance in Format / Style / Lyrics, as your value of 4.5 - no doubt chosen to work around other deficiencies in 2.x - is now also much too large. The default of 2sp works better. Just those two changes alone go a long ways, then if you need further assistance with specifics, feel free to ask!
EDIT: oh yeah, you did ask about other specifics. By "double hyphen" I guess you mean the places where the lyrics are widely spaced so MuseScore now follows more standard engraving rules about when to use multiple hyphens. You can customize this in Format / Style / Lyrics. As for the Rall, it seems you tried manually creating a line using dots, but that's going to be very fragile as it is going to depend too much on the specific measure widths etc. Much better to use a normal line for this, so MuseScore can adjust the length automatically. This was true in MuseScore 2 as well - your approach would have failed the moment you made any change to your score that affected layout.
To me, this is also a major problem. I have many scores, especially Ancient Music scores edited exactly the way I want them, and the styles saved in MuseScore 2. I can't use any of them in MS3 anymore because they look totally different.
I also hope there will be a backward compability with MS2 or a function which keeps the exact settings of MS2.
Attached a MS2 sample.
In reply to To me, this is also a major… by Rolf Maeder
If you want your MuseScore 2 files to look like they did in MuseScore 2, don't use MuseScore 3 on them. Same was true between MuseScore 1 and 2, a couple years ago. MuseScore 1, 2 and 3 coexist peacefully next to one another on the second computer and even running at the same time.
I only now realize that the single biggest problem users like me are having is a misunderstanding of what MuseScore 3 was intended to be. At https://musescore.org/en/node/283922 mike320 has posted a document that explains it very concisely. Such an explanation should have been, and might well become, a must-read readme-type notice attached to the MuseScore 3 installation process. (Marc, bless him, couldn't refer to this document earlier, because it wasn't posted until Feb. 10, 2019.)
To paraphrase the document: Rather than a continuation and refinement of the MuseScore 2 paradigm, which has (apparently) insurmountable limitations for the automatic placement of tempo, dynamics, and other markings, MuseScore 3 was a radical rethink of how algorithms can work to make a score "look right" with minimal user effort.
Currently, the new auto-placement feature is incompatible with many of the manual placement tweaks that were necessary in MuseScore 2. That said, I'm convinced that MuseScore 3 has a few bugs that unnecessarily prevent conforming certain MuseScore 2 scores to be editable in MuseScore 3. My guess is that those bugs will be fixed soon. Going further out on the limb, my guess is that the MuseScore developers will eventually find a way to coordinate the older manual placement tweaks with the newer auto-placement function, so that opening an older MuseScore 2 score in MuseScore 3 will require minimal effort to conform the older score to the newer way of working. I believe that in time, such backward compatibility will become nearly perfect, and we'll no longer need to keep MuseScore 2. In the meantime, we just gotta do what we gotta do and have some patience.
Please read the post at https://musescore.org/en/node/283922!
In reply to I only now realize that the… by WStites
As the author of https://musescore.org/en/node/283922, I would like to say that I set out to explain how things are in version 3 and the thought process necessary to make the mental transition from version 2 to version 3. I don't foresee version 3 ever displaying a version 2 score exactly as it was in version 2. There are some good reasons for this and some bad reasons for this.
Good reasons include the fact that the code that draws certain items has been totally rewritten for version 3. This was in part necessitated by the auto placement algorithm. These items, one prime example is slurs, will never be identical in versions 2 & 3. Another good reason is that people frankly did and now continue to try to do things that are ill advised when it comes to making the score look the way they want it to. As an example, one extremely bad decision I saw in version 2 was the person who dragged all of the rests from a piano score off the page rather than simply selecting them and pressing V. Version 3 should never consider take user decisions like this into account.
Down the middle of the road, programming decisions that are questionable but understandable include things like Hairpins. Insufficient information was stored on hairpins to ensure they are displayed the same in both versions 2 and 3. This was apparent in version 2 by the problems with the wondering hairpins when scores were closed and reopened. This is related to both bad decisions by users and bad programming decisions that kept these from working in version 2. There are others, but this is by far the most common.
Bad programming decisions are in the category of items that can be properly calculated, but are not. Like the locations of articulations, ornaments and lyrics. The global settings seem to be ignored when importing from version 2 to 3. Part of the problem with this is that the settings in version 2 may not make sense in version 3. I like my dynamics a little closer than the defaults in both versions 2 & 3, so I manually change the style settings to show this in my scores. Unfortunately, version 3 doesn't care that I made the change in version 2 so I have to redo this in version 3. Is this a bad programming decision? I'll let you decide. Another decision is that every hairpin in version 2 that is preceded by a dynamic has to be manually adjusted to prevent a collision, but version 3 does this automatically. How does the program decide which adjustment is legit for anti collision and which is for aesthetic decisions by the user? The bottom line is that bad programming decisions are difficult decisions to be made and are the main reason you likely will never have a version 2 score look identical in version 3. Bad programming decisions are also very subjective, so in spite of my many criticisms of version 3, I'll give the programmers a pass on these decisions.
In reply to As the author of https:/… by mike320
Good points, I will just address a couple of things I have doubt about.
I don't think it was a decision to not import text style settings when importing from 2.x. I think it was more of a question of the import code just not being fully written. We actually make a pretty concerted effort to preserve manual adjustments of dynamics, for instance, even to the point of detecting dynamics that were manually moved above the staff and converting them to "above" placement and adjusting the offset accordingly. To be honest, I have no idea why we don't import the dynamics text style and convert it to the dynamics position below. Probably if you submitted it as a bug report, it would get fixed. I know sometimes it's tricky because many elements now have separate "above" and "below" settings, but we should be able to figure out a reasonable strategy. Luckily, tweaking style settings is relatively easy compared to manually adjusting potentially thousands of settings, so maybe less attention was paid to this.
As for hairpins, this is a good example of why the "reset" is often a good idea - if you accept the reset, you'll get a hairpin that avoids the dynamics in the same way as you manual adjustment otherwise would have. But actually, in this particular case, we also do a pretty good job in my experience of preserving your manual adjustment, so you get results either way. At least for the case I have tested. If you are seeing cases where this isn't so (not clear if that's what you are saying), again, please submit a bug report so we can investigate.
In reply to As the author of https:/… by mike320
Main issue with new format is that it kept the same extension so there is no way to make distinction between MuseScore2 and MuseScore 3 files.
Also, double click opens all files in one of the MuseScore versions which is very annoying when wrong version is hit.
So, my suggestion is to introduce new extension, like .mcz3
In reply to Main issue with new format… by Pedja
MuseScore 3 can read them all, so make it the default for .mscz. It is automatically if installed in the 'natural' order.
Changing to .mscz3 now would mean that all earlier MuseScore 3 versions won't be able to open them, so that is not going to happen.
Maybe, one day, for MuseScore 4, if and when that happens, .mscz4 might be an option...
In reply to MuseScore 3 can read them… by Jojo-Schmitz
Thanks, I will try that.
In reply to MuseScore 3 can read them… by Jojo-Schmitz
Well that is not an issue as they are not compatible anyways
In reply to Well that is not an issue as… by Pedja
The solution is simply providing conversion tools that will update legacy files properly, apply new tags and automatic formatting with the least amount disruption.
I will repeat this, because I believe it is a very important point...
The purpose of the software is to always be forward looking and should not necessarily be restricted by limitations of past versions. The gap between past and present does not necessarily have to be resolved in the software itself, but through conversion tools/services that can more effectively close this gap.
To force the software to remain backward compatible is to limit the future potential.
There are some conversion tools currently in testing. Stay tuned.
In reply to The solution is simply… by Daniel
I agree. That is why I proposed extension to change with the version. Now, there is no way to distinguish MuseScore file saved in old and new format an formats are not compatible. If different file name extensions are used, then each file could be opened with apropriate version of MuseScore.
In reply to I agree. That is why I… by Pedja
They are compatible, upwards, between major version, and also downwards between minor versions
In reply to They are compatible, upwards. by Jojo-Schmitz
My experience is quite opposite. None of my MuseScore 2 files opened properly in MuseScore 3.
In reply to My experience is quite… by Pedja
“Properly” is a relative term. The default layout is much improved, so many scores look better. But scores with lots of manual adjustments - particularly ones me to workaround deficiencies in the default layout of MuseScore 2 - may indeed need some adjustment.
In reply to My experience is quite… by Pedja
All opened, right? None of the version 3 ones open in 2
In reply to I only now realize that the… by WStites
I’ve ported my styles to MS3 and sat down to enter a new score from IMSLP in it today, because MS2 is not a long-term solution and only viable for old scores.
What I found is that the auto-placement algorithm causes there to be much more space around and between items (whereas leaving not enough between others), and no “take autoplace and then apply this offset” is possible (e.g. to fix the utterly bad cresc/dim offset). This means it’s basically not possible to create tight (positively spoken) / cramped (negatively spoken) scores with it.
For the general user base, who wishes to make something, and let it look good with minimal effort, this is good.
For those among us who want to squeeze good page turns out of smallish paper (DIN ISO A4 in my case), this may be not so good. I’ve removed some of my styles that made distances narrower, and go with the realisation that MS3 just cannot handle three SATB systems on one A4 page, period. Taking this into account, I can understand the new model and go forwards with it.
For when someone needs the tight spacing… I understand the requests for a per-score global disablement of the autoplacing/skylines now. It’ll be easier to go with 2.3.2 for that… but only for a while; eventually, it will be no longer compatible with the libraries in newer Debian versions, so I know I have to migrate cough (pretty much: completely redo/relayouy) my MS2 scores to MS3 eventually, and either live with the new wider spacing or find a way to do things without autoplacing.
Thankfully, I don’t publish books in which pages are expensive. I print for myself and let others print for themselves. But I expect those who do to create house style MSS files and disable autoplacement for a score globally. Not that this is a bad thing.
MuseScore 3’s autoplace algorithm optimises for the common case, not the specialist or pathetic case. This is a good decision, from a general software engineering PoV. It just means that those for whom the defaults are not so good need to do a bit more to squeeze out what’s necessary. But I can live with that.
Plus side of going MS3 with all scores: configurable lyrics hyphen min distance (going with 5 sp for now, looking good so far, but I’ll have to see it in print), and system dividers!
But if I’m only going to have two systems per page anyway, perhaps these could be aligned in a way that they always start at the same vertical position on the paper, so turning the pages has less optical flicker? The first page has a 10 sp header, but it still fits two systems, so the music on the following pages could just start lower on the page… hmm… (I think I did that in MS2 once, but autoplace makes the exact spatium positions/distances harder to figure out).
In reply to I’ve ported my styles to MS3… by mirabilos
Can you show examples of where you are having trouble getting spacing as tight as you want? I just submitted a PR that should make a big difference for lyrics - see #284235: Too much space between lyrics. For a number of other elements, there is an "autoplace min distance" style setting you can use to reduce the padding. For other elements, there isn't yet such a setting, but adding one would not be hard, so make the request and maybe it happens.
In reply to Can you show examples of… by Marc Sabatella
No, not lyrics. Things like https://musescore.org/en/node/284341 or that, when you enable autoplace on a dynamic (the only dynamic in a stave, for this example) on A/T/B, then the stave distance suddenly increases by quite a lot. Small things like that. I don’t even see this as a problem.
In many other cases, such as your convoluted example from the other post, they are actually too tight.
As I said, the algorithm produces decent output, but it’s more sparse/spaced than people are used to.
In reply to No, not lyrics. Things like… by mirabilos
More spaced, sure, because previously you'd get items direction on top of each other. For example, here is the MuseScore 2 version of the example I've posted elsewhere:
As compared to MuseScore 3:
Sure, it's more spaced than in MuseScore 2, but I can't see any sense in which is a bad thing. In particular, you said you were having trouble getting things as tight as you want - you are saying you would want things tighter than what MuseScore 3 gives here? I suspect not. Which is why I'm looking for a specific example of a score where MuseScore is not as tightly spaced as you'd like, and where MuseScore 2 did a better job somehow. If there is a way to improve, I want to implement it, but real examples would help.