V3 file extension should not be the same as V2
V3 files are not compatible with V2, and therefore should have been assigned a new file extension.
It is expected that finished V2 scores with complex layout are not "reworked" in V3 but kept in V2 and that people keep V2 available on their computer because reading these files with V3 respecting the V2 layout is impossible (or requires possibly long rework of the file).
The choice to not implement V2 layout in V3 to keep the code manageable and maintainable makes sense (even if end users would have preferred otherwise).
But asking to use different folders and to remember which ones contain V2 scores and which ones contain V3 scores is a pity.
Comments
you did not make a suggestion. I'll add a couple of:
1. msc3z; .msc3x
2. mc3z; mc3x
3. m3z; m3x
4. mu3z; mu3x
In reply to you did not make a… by Ziya Mete Demircan
I like .ms3x and .ms3z.
In reply to you did not make a… by Ziya Mete Demircan
I like these too. How I read them (for anyone wondering why this could work):
.ms3x - MuseScore 3 extracted
.ms3z. - MuseScore 3 z = compressed
Mscz file are upward compatible, bit not downwards. Same thing happened between 1.x and 2.x.
In reply to Mscz file are upward… by Jojo-Schmitz
<< Mscz file are upward compatible >>
No they are not, by having chosen to not reimplement the V2 layout engine in V3 to keep the code clean and manageable.
You can't open V2 files in V3 with major work to relayout your score.
In reply to << Mscz file are upward… by frfancha
MuseScore 3 can open files from 2 and 1.
MuseScore 1 cannot open files from 2 or 3
MuseScore 2 can open files from 1 but not from 3.
Opening 1 files in 2 also requires redoing the layout.
1, 2 and 3 can be installed and running on the same computer, for exactly that reason.
In reply to MuseScore 3 can open files… by Jojo-Schmitz
And for exactly that reason as you say, having V2 and V3 installed on the same computer require that file extensions are different to avoid being lost in managing the different score versions that you use.
In reply to And for exactly that reason… by frfancha
Au contraire...
If you installed them in the 'natural' order, 1,3, 2.3.2, 3.0.2, the last one registers for opening mscz/mscx and can open them.
If you want to open a score with 2.3.2, either starte that ans use file open or use right-click > Open with.
My modus operandi since 9 years, for 1.x and 2.x, and now also for 3.x.
Changing extensions for 3.0 is not going to happen and way to late anyway. Just get over it, that bird has flown.
Who know, maybe 4.0 might change this, but I really doubt it.
In reply to Au contraire... If you… by Jojo-Schmitz
<< If you want to open a score with 2.3.2, either starte that ans use file open or use right-click > Open with. >>
Which makes the recommendation to keep finished complex scores in V2 cumbersome.
Even more if you have to remember which one is V2 and which one is V3.
<< Changing extensions for 3.0 is not going to happen and way to late anyway >>
Could be done in 3.0.3 without problem.
In reply to << If you want to open a… by frfancha
And introduce an incompatibility inside the 3.x stream? Won't happen.
I still maintain some 400 1.x scores, which I can't (!) migrate to 2.x or 3.x)
I still use 1.x/2.x for small corrections to 1.x/2.x scores, like correcting a typo or athe odd wrong pict or layout glitch
I do create new scores with 3.x and I migrate older scores to 3.x if and when larger changes are due
In reply to And introduce an… by Jojo-Schmitz
Which incompatibilities ???
The fact that new save from V3 would use a new extension doesn't prevent at all to open existing V3 files.
Does one or more of the major OS vendors recommending changing file formats for this? I don't recall this being the norm for the many times other programs made similar changes to their file formats.
Using different folders is the default, so it's not really asking anything we aren't giving for free...
In reply to Does one or more of the… by Marc Sabatella
<< Does one or more of the major OS vendors recommending changing file formats for this? >>
Of course they do.
When file format was changed in a incompatible way in Office 2007, xls => xlsx, doc => docx ....
And the change was less important than MuseScore: Office 2007 can open xls/doc without needing to relayout your document, and Office 2007 can save doc/xls to allow older version to read it.
Here the gap between MuseScore2 and MuseScore3 is much bigger: you can't open V2 in V3 without relayout work, and you can't open V3 in V2 at all (I know MusicXML but if you go that way MuseScore is compatible with Sibelius).
Relying on folder doesn't sound like the smart advices you usually give, when you share a file would say: "Oh by the way look at the folder from which I have copied to know which version it is? All the ones in the Mozart Folder are V3 now, but the ones from the folder Bach are still V2 except the fugas which were already done...
And what about people having different folders with scores (which is natural), some of them already converted, other ones not? Are forced to duplicate the full folders tree to split V2 and V3?
For new users not having contact with other MuseScore users to share files it isn't a problem, but for all users having a important number of V2 files that is unmanageable.
I hear that the behaviour from V1 to V2 was the same, but repeating errors is not mandatory for MuseScore (I hope) and the number of MuseScore users and the number of carefully done V2 scores incompatible with V3 is much more important now than 4 years ago.
In reply to << Does one or more of the… by frfancha
You cannot install different versions of Word so they need to be back and forth compatible, also they do have hundreds of programmers at work
In reply to You cannot install different… by Jojo-Schmitz
Forcing users to install many versions of a software just to be "compatible" isn't a good practice:
Having one file extension for every version of the layout engine of the software is good because:
SaveFileDialog savefile = new SaveFileDialog();// set a default file name
savefile.FileName = "unknown.mscx_newversion";
// set filters - this can be done in properties as well
savefile.Filter = "MuseScore NewVersion files (.mscx_newversion)|.mscz_newversion;
Also, how hard would be to add a program routine to MuseScore to automatically open the "Save As" dialog whenever an old score was opened and the user chooses to use the "File Save"? I can think of a boolean variable "older_version" which would be populated when opening the file and would be read by a "File Check older version" function to call the "Save As" dialog or the "File Save" function whenever the user uses the "File Save" menu option or toolbar icon.
(Sorry, but I can't contribute my developing skills to MuseScore as I am no developer, I am a PowerShell scripter which has some notions of C#, the language PowerShell was based on).
Also, the file extension is just to ease the user life and show a proper icon on the system shell, what MuseScore really uses to identify the files it opens are the so called "magic numbers" inside them, not the file extensions.
In reply to Forcing users to install… by joaopaulo1511
I think I found all the files on the source code that needs to be changed:
In the first, change the lines that have ".mscz" and ".mscx" could be changed to ".mscz_newversion" and ".mscx_newversion" (of course the lines that refer to the File Open Dialog should just add the new file extension instead of substituting it).
In the second, add lines to make the MSI file register the new extension.
In reply to << Does one or more of the… by frfancha
I'm not sure if .doc was same format in Word 95, 97 and 2007, but .docx is completely different. When Microsoft introduced "x" file format I knew that I had to buy a new version of Office. Now, MuseScore is free and open source software and what most people do is just download new version.
Even if today backward compatibility is not perfect, it may be improved. Sooner or later, users will update, so in my opinion there is no point in introducing new file extension.
In reply to I'm not sure if .doc was… by woland
And docx is even a standardized format, not propriatary like doc. If you want that in MuseScore, use MusicXML
In reply to I'm not sure if .doc was… by woland
No need to update Microsoft Office to open .docx files -- try with OpenOffice at zero cost.
In reply to << Does one or more of the… by frfancha
You say "of course" the major vendors recommend this in situations analogous to ours - can you please point me to the relevant link, then?
The situation with Word is very different than ours in many ways, and in any case, just because the Office team chose to do this with Word in a couple of specific situations doesn't mean the Windows team recommends everyone do it in all situations. I am interested in seeing the exact wording of the guidelines.
As for sharing files with others, if I needed to do that, I would say: "this is a MuseScore X file, be sure to treat it accordingly".
In reply to You say "of course" the… by Marc Sabatella
Microsoft recommends using a file type for a new application here: "https://docs.microsoft.com/en-us/windows/desktop/shell/how-to-register-…". It's worth noting that when a new version changes its behavior (such as its layout engine) in a way it no longer display correctly the file, or even no longer produces files compatibles with older versions of the software, it is a new application.
Also, Microsoft recommends using programmatic identifiers (ProgID) to register side-by-side applications here "https://docs.microsoft.com/en-us/windows/desktop/shell/fa-progids" and here "https://docs.microsoft.com/en-us/windows/desktop/shell/fa-best-practice…". Microsoft even provided as example the ProgIDs for Word.Document.6 and Word.Document.8, and in my machine there is also Word.Document.12 (the version which first registered the .docx extension).
Although I don't recommend using unsupported old versions (because security issues) of a software side-by-side with the new, supported version, using versioned ProgIDs allows for:
1) Retaining all installed versions registered to "Open With" the common file extension;
2) Allowing a user to install the software versions in any order without breaking the rule of making the newest version installed to be the default file extension opener (remember users are prone to errors);
3) Allowing the use of more than one file extension, as each .mscx/.msc2x/.msc3x/.msc4x (for example) would be registered to to its own versioned ProgID for MuseScore, instead of the same ProgID for all MuseScore versions as it has been the case.
Please, please change the file extension to make it easier for the user!
In reply to Microsoft recommends using a… by joaopaulo1511
It’s too late now, no matter how good the arguments are.
By now, 3.x is stable, and changing anything will artificially break compatibility within an existing stable series with no means for compensation, where no incompatibility exists.
You had until December 2018 to bring forward these arguments. Now, the train has left.
I VERY STRONGLY support frfancha's notion. This has been bugging me since I started working with MS3 (it is my first transition between major versions), but was still trying to find the time to post. (disclaimer - I was part of the alpha/beta cycle and should have raised this then). In my opinion (and it is just an opinion, based on the below), the whole transition from v2 and v3 has been anything but transparent (since this issue has multiple touch points, I try to make a recommendation to fix, where I can. This is just a first attempt in most cases, the jumping off point for discussion):
In reply to I VERY STRONGLY support this… by Riaan van Niekerk
When downloading a v3 file from MuseScore.com you have no way of telling what you are downloading.
This indded needs to get fixed. On musescore.com, so request it there, in https://musescore.com/groups/improving-musescore-com/
I always though Guitar Pro having all those different extension versions was strange (.gtp, gp3, gp4, .gp5 ...
This is the mess MuseScore tries to avoid
In reply to When downloading a v3 file… by Jojo-Schmitz
State explicitly whether a downloadable .mscz file is MuseScore version 2 or 3 created. Hoping they look at it.
gp3/4/5 may look like a mess to someone who is used to seeing different versions of a program (MS Word) able to save to the same standardised file format (eg. Word 97 – 2003 (.doc)) across multiple generations, but it is an acceptable compromise for a small dev team (Guitar Pro, MuseScore) that would rather spend limited resources implementing new features than implementing backwards compatibility save filters.
For the dev team (who ultimately decide which features go in for the mere fact that they are coding and merging them) to adopt the single extension approach to avoid extension version sprawl is very unfortunate, since it implies that you deny there is any problem.
If you had to deal with this deficiency for years (like any MuseScore stalwart would have), and accept having to organise scores in folders by version number as a solution, not a workaround, you might consider that normal. But the fresh pairs of eyes that have not lived with this issue, see it very differently.
In reply to I VERY STRONGLY support this… by Riaan van Niekerk
Broken link to issue. Correct one #283063: "MuseScore File" string (under File -> Save As...) does not indicate which version you are about to save as("MuseScore File" string (under File -> Save As...) does not indicate which version you are about to save as)
If users are worried, there is a reason.
and It is a bad habit to rush to release the new version and then say: "Too late to fix it now".
Programmers, Developers (and/or software companies) may think: "Let's endure; they'll get used to it automatically after a while", right?
A big "No"!
And yes: GuitarPro's approach is very positive. I have different versions of gp (n) files and I can work without problems.
File extension registration may have a number of difficulties (time, acceptance, generalize, etc.). But it is worth it.
When MuseScore invented the .sf3 file format, no one opposed it.
Well, why not mscz3?
In my humble opinion, while managing his files on a PC one has to pay great attention to ORDER. I have been used to it since eons ago, so I can't see any problem in storing my MuseScore files in different folder ierarchies based on the version of the files. Moreover, one could simply add a note somewhere on the score page, just as a common string of text in a small, non-intrusive font saying "MuseScore X document" (where "X" is the version of the program).
In reply to In my humble opinion, while… by Aldo
<< one could simply add a note somewhere on the score page, just as a common string of text in a small, non-intrusive font saying "MuseScore X document" >>
Sorry but this suggestion shows that you don't understand the issue.
You just can't open V3 with V2 at all, and opening a V2 with V3 will pop up a dialog box (reset yes/no), if you reset you get an acceptable score but changed compared to V2 and requiring some fine tuning, and if you don't reset you get a mess. So your notice in the score is completely useless, one way you just wouldn't see it at all by not being able to open the score, and the other way you already pretty well know that this score was still V2 by the reset process.
And, to be clear:
=> this issue is NOT that you can't open V3 with V2 or that you can't open V2 with V3 keeping the same layout, I understand the reasons behind that
=> the issue is about the fact that running V3 next to V2 on the same system, which is necessary due to the previous choices for people having large collection of complex V2 scores ad is recommended by the MuseScore gurus here, is much more complex than it needs to be by sharing the same file extension.
A) Scores are already organized by folders and forcing people to maintain a parallel structure for V3 and for V2 is poor, I want all my scores "Musique Piémontaise" in the same folder not some under V2 and other ones under V3
B) Double click score to open it in the correct version will only work for one of the version (at OS level you have to chose to associate the extension with V2 or V3), so for the "other" version you must open from the software or right click and select "open with", very poor experience.
In reply to << one could simply add a… by frfancha
What about the following solution:
provide a filter in a new version of V2 that allows to import V3-files while ignoring the new items that have been introduced with V3.
I think, this is not a big deal and would make everybody happy.
By the way: MS office did something similar by providing some sort of filter-plugin that allows older versions to lead newer version file formats.
In reply to What about the following… by Bacchushlg
It wouldnt make anybody happy and doesn't answer the issue here being managing collection of V2 files and V3 files on the same system.
Plus, the layout engine being completely different between V2 and V3 makes your proposition undoable.
Finally if you really want to send score content from V3 to V2 you can do it by musicxml.
In reply to It wouldnt make anybody… by frfancha
Sorry, but I don't agree: If a new version of V2 could read V3 files, I could open every file with this V2-version (which still supports all available plug-ins, for example).
But of course: the dev. effort for doing this must be acceptable. If layouts are really so completely different as you describe, then the only way is: musicxml.
In reply to What about the following… by Bacchushlg
MuseScore 2 won't receive any changes or fixes anymore, dead end road.
In reply to MuseScore 2 won't receive… by Jojo-Schmitz
I thought that was open source and people were free to continue development if they wanted? Or is it owned by a company and locked?
In reply to I thought that was open… by frfancha
Oh, OK, I see. Of course it is open source. Feel free to create your own MuseScore. It won't be compatible with every one else's though.
MuseScore 2.3.2 is and will be the last version coming from musescore.org.
In reply to Oh, OK, I see. Of course it… by Jojo-Schmitz
Ah so MuseScore.org will refuse any PR patching bugs of 2.3.2?
In reply to Ah so MuseScore.org will… by frfancha
Yes. All development is on master now, and that all goes into MuseScore 3.x, for time being, and maybe eventally into MuseScore 4. MuseScore 2 officially reached its end of maintainance with 2.3.2.
In reply to Ah so MuseScore.org will… by frfancha
I hope that some critical issues, e.g. security-relevant, would still receive attention.
I’d just patch them in the Debian package locally else… at least in distributions, software is typically maintained for longer, and I expect to be “maintaining” MuseScore 2.3.2 in Debian for another 2–5 years (with LTS now), although the scope is limited by stable update policy (i.e. security and critical bugfixes only). Collaboration on those, when necessary, will be welcome.
(This is because the next Debian stable is about to be released. I’ve updated the Debian musescore packaging with smaller patches from time to time before that, even going so far as to add new features. That being said, since musescore.com won’t ever see these new features for 2.x scores, you won’t have much luck with them except locally. Nothing incompatible, though.)
As for the file format… it’s waaaaaaaaaaaay too late to change it now anyway, and I’d prefer to avoid the gtp mess as well. I currently determine the format of a file by running
xmlstarlet sel -T -t -m /museScore -v @version -nwith the mscx file on stdin, then see whether the resulting string begins with2.(MuseScore 2.x),3.(MuseScore 3.x) or anything else (not prepared to handle it), but unfortunately, nobody wants to commit themselves to specifying at least parts of MSCX so I’m prepared to change/update my detection algorithm at any time. (The xmlstarlet command basically reads the “version” attribute from the (outer-most) “museScore” XML tag and prints it. Used to be regex, but one doesn’t parse XML with regex, period.)In reply to In my humble opinion, while… by Aldo
"simply add a note somewhere on the score page, just as a common string of text in a small, non-intrusive font saying "MuseScore X document" (where "X" is the version of the program)."
That is what a file extension is there for, where you can see on face value which versions of a program will be able to open it. What purpose would the text / note you described serve, if you need to be able to open the file to read the note? If you got that far (opening the file), it is pretty safe to assume that the file is compatible with the version it was opened in.
I (as I suspect many others) use folders to organise files by something other than version number. In my case I have a folder per song/piece, with .mscz, PDF parts, midi, notes etc.. The only acceptable workaround I could come up with (that works for me), is putting the version number in the file name, e.g.
song.mscz for MSv2
song_v3.mscz for MSv3
This avoids the notes, the folders, having to tell someone that what I am sending them is a MSv3 file.
I Do believe it can be quite confusing, since (on Windows at least, and I guess it's the same almost everywhere), same formats are automatically opened by the same softwares, but I don't think it is a good enough reason to create a .ms3x or whatever file format.
However one thing I would add is an "open in Musescore 2" button in the message box appearing when you open a musescore 2 file. The one saying something like "your file will be relayouted".
In reply to I Do believe it can be quite… by ecstrema
@Marr11317 Nice try, but that would require that MuseScore3 was able to detect if MuseScore2 is installed on your system and where (which is just impossible for portable version), without even mentioning that the "system" could also be another computer sharing the family NAS.
As @mirabilos said, its way too late for this now that MuseScore 3 has been released, and I'm not sure I would support it even if MuseScore 3 hadn't been released because while some programs do this, the vast majority do not.
However, what I would consider supporting is for development builds to use a different file extension to stable releases. This would make it easier for people to test development builds without fear of accidentally overwriting their main scores potentially making them unreadable by the stable release.
I don't expect the problem will be as severe in future, because future releases will undergo more testing and be more stable from day 1, hopefully to the point that there will not be the same need to support two versions at the same time.
MuseScore 3 was probably the last version to be released according to the waterfall model of software development. Starting from 3.0.1 we switched to an iterative model, which will result in issues being identified sooner and fixed faster. This should mean that the transition from MuseScore 3 to 4 will be a lot smoother than 2 to 3, so hopefully there will not be the same need for multiple versions to be in use simultaneously.
In the meantime, as suggested by various people above, you can make the transition from 2 to 3 easier by:
In reply to As @mirabilos said, its way… by shoogle
@shoogle
"its way too late for this now that MuseScore 3 has been released"
=> no it is not. MuseScore could perfectly save by default with a new extension starting from 3.0.4 e.g.
"the transition from MuseScore 3 to 4 will be a lot smoother than 2 to 3, so hopefully there will not be the same need for multiple versions to be in use simultaneously"
=> Perfect. So that means that introducing a new file extension now will be a one time operation and not the first step in a long series, so no 'GP mess' (as someone has called it) will be created
"Add "v2" or "v3" to the filename."
=> That's indeed necessary, and the ultimate proof that a different file extension IS necessary, having to ask users to "implement" it by themselves changing file name is [/censored]
In reply to @shoogle "its way too late… by frfancha
Of course it is possible to use a new file extension for 3.0.4, but now that there are already v3 score using the old extension "in the wild" this is not going to happen.
In reply to Of course it is possible to… by shoogle
And such a major change in a patchlevel version is against all rules of software development.
I’ve had a peek at files from other notation software, and all I looked at use the same file extension, and when you use newer features, you can’t use them with the older version. That’s normal.
In reply to And such a major change in a… by mirabilos
"I’ve had a peek at files from other notation software, and all I looked at use the same file extension, and when you use newer features, you can’t use them with the older version. That’s normal."
This comparison completely misses the main point: in these "other" notation software, opening a previous version file with a newer version preserves your layout and therefore keeping several versions of the software active on your computer is not necessary, and therefore, indeed, in these "other" notation software using a different file extension is not necessary. But it is for MuseScore V2/V3, and hopefully for the last time.
In reply to "I’ve had a peek at files… by frfancha
Just curious - have you actually tried opening a score created in, say, Finale 3.1 using each successive new version of Finale up until the change to MUSX in 2014 - did the layout really remain unchanged all these years? And opening a Finale 2014 today - no changes whatsoever? How about Sibelius when it implemented magnetic layout? Some real data would help the case here.
Certainly I've used any number of photo editing programs ("RAW" processing) in which opening the same photo in different versions would produce different results, in fact that's more the rule than the exception. So again, to me, this is perfectly normal and expect that it will happen from time to time, without the enormous nuisance of a change in file extension.
In reply to Just curious - have you… by Marc Sabatella
True. Even Adobe does not seem to care about backward compatibility of recent Photoshop and some older PSD files.
In reply to As @mirabilos said, its way… by shoogle
Hi shoogle,
dev versions already use a different path (MuseScore3Development) by default, so a different file extension is not necessary. (It would be rather annoying, actually.)