MuseScore 4 must use a new file extension

• Jun 8, 2020 - 17:52

If MuseScore 4 has a different file format than MuseScore 3 and MuseScore 3 is unable to open MuseScore 4 files, then MuseScore 4 must use a new file extension.

Comments

• Jun 8, 2020 - 18:57

No it must not (ans I do know that "must not" is not the opposite of "must" ;-)).
MuseScore 3 didn't use a different one from MuseScore 2 and that not a different one from MuseScore 1 and that was good. IMHO...
It just needs to import the older formats cleanly.

Reply

• Jun 8, 2020 - 21:05

I would like to add a vote for a new extension for Musescore 4

Two reasons why I would like this:

  1. Users (like me) who keep old versions of their scores produced under Musescore 2 in the same folder as later versions which have been imported to Musescore 3 and then saved can not see before they open the file which Musescore version is relevant for that score.

  2. I have some published versions produced in Musescore 2 and if I want to have another exact copy I have to use Musescore 2 to reprint them in exactly the same form as they were produced. If I open them in Musescore 3 there is a danger that if I close Musescore I will forget that I am working with an import and say yes to save changes (thinking as I have done no editing it must be referring to something like changes to the print settings only) and overwrite the Musescore 2 version which is then lost for ever. That danger would be very much reduced if after importing to the new MuseScore version and saving, the file would have a different extension.

Excel did it. .xls files still open in newer versions of Excel and can be saved as .xlsx without destroying the .xls version.

What are the reasons for not liking a new extension?

Reply

• Jun 8, 2020 - 22:54

But Microsoft did use a new extension. They must have seen advantages as I do for Musescore, probably different advantages to those relevant for Excel but advantages nonetheless.

Of course not using a new extension is possible. But just because it is possible doesn't mean it is a Good Thing. So, to repeat the question: what are the advantages if Musescore 4 doesn't have a new extension?

Reply

• Jun 9, 2020 - 08:27

If l understand correctly then,
in contrast to the introduction of .xlsx and xml format, there will be no changes to the .mscz file format that would break backwards compatibility. That would be good and indeed would remove the advantage of changing the extension.

Reply

• Jun 9, 2020 - 09:09

That's not being said. MuseScore 1, 2 and 3 all use mscz, but did change the internal format, so older version can't read scores created with the newer versions.
Whether or not MuseScore 4 does change the file format in a similar not downwards compatible way is yet to be determined, but IHMO no good reason to change the extensions. There wasn't a good reason in the past for that and there is none going forward

But indeed if there is no (downwards incompatible) file format change, then it would be really stupid and entirely useless to change the extension.

Reply

• Jun 9, 2020 - 10:10

Well, I gave some reasons (maybe you think they are not good reasons) but I have not yet heard of reasons why there should not be a change of extension. There are going to be pros and cons in changing the extension. Rather than trying to shoot down the pros, why not humour me and provide a few of the cons. Or aren't there any?

Reply

• Jun 9, 2020 - 10:25

Change isn't good all in itself, so if there's no (good) pros, why needing cons?

  • Confusion. "mscz" is the MuserScore extension since Pleistocene
  • Having more extensions to load files from in the File > Open dialog
  • Adding more registry keys (Windows) for registering MuseScore for those additional extensions, similar issues for Mac and Linux, albeit using a different mechanism.

Reply

• Jun 9, 2020 - 11:49

Ok, I'll take the bait :-)

  • Confusion. "mscz" is the MuserScore extension since Pleistocene

Many things have changed since the Pleistocene. Humankind can probably cope with one more change.

Personally, I find it confusing trying to keep track of which version of Musescore I last used to edit a score without the benefit of a heavy hint from the file extension.

  • Having more extensions to load files from in the File > Open dialog

a) I assume there would be a modified icon as well. I would guess most users select file by icon rather than extension. Indeed, many users probably never see the extension.

b) A different extension would avoid MuseScore 2 and 3 showing incompatible MuseScore 4 files in their open file dialogues. (Another pro for the list!)

  • Adding more registry keys (Windows) for registering MuseScore for those additional extensions, similar issues for Mac and Linux, albeit using a different mechanism.

Again, most users never see a registry key.

If it can't be done then fine; we have to live in the world of the possible. But this seems to be more of a plea to keep life simple for developers. Surely convenience for the user should have higher priority. And developers love the challenge, don't they?

Reply

• Jun 9, 2020 - 12:26

Actually the double entries in the windows registry is a good reason to duplicate extensions.
As when MuseScore 4 will be out, even more people than at MuseScore 2 time will have lot of scores that they will desire to keep under MuseScore 3 to avoid to take time to rework them.
Ability to associate MuseScore 3 extension with MS3 and MuseScore 4 extension with MS4 will be appreciated.
Now, that's on the hypothesis that the layout engine between V3 and V4 is dramatically changed as was the case between V2 and V3.
If the score format of V4 is incompatible with V3 BUT opening a V3 score in V4 displays it (almost) like it is displayed in MuseScore 3, then reason to keep MuseScore 3 active on your computer disappears, and therefore reason to have different extensions disappears as well.

Reply

• Jun 9, 2020 - 13:11

Well ideally. They shouldn't have to rework them. If they do, its a bug that would need to be addressed. People shouldnt have to use unsupported versions where development has stopped. Eventually those stop running (maybe after a long while, maybe not). Therefore this coversation is moot. Why should anyone care their 3 score cant be opened in 2? 2 is dead. The whole point of the project is that a score i create now will run 10 years from now in a future version of musescore. I dont want to run some x86 emuator to run ancient musescore. What good is that to anyone? Forget ancient qt libraries and what not... Just thinking about that makes me realize how many extensions is a bad idea for future compaibility. Great....my compositions are forever locked in a time capsule and only good for musescore 3....I support open-source software to get away from that kind of crap.

Reply

• Jun 9, 2020 - 13:43

No, it isn't a bug.
It is a conscious design decision of MuseScore to not spend time to implement V2 layout engine in V3.
And regarding the usage of V2 for small edit of V2 scores having complex layout adjustments, it is not my recommendation, it is the "official" (and perfectly reasonable) position of the experts on this forum.

Reply

• Jun 9, 2020 - 13:35

Once a score has been successfully migrated from 2.x to 3.x there indeed is no reason to go back to 2.x with it.

But also, as long as the downrev version is still available and working, this is the recommended way for minor edits, like fixing a typo of a wrong pitch. Esp. if that downrev scrore uses a lot of workarounds and manual positioning that are biting back hard with the newer versions layout engine.

So far I'm not aware of any older MuseScore version to not run on newer operating systems, as far as I can tell 1.3, 2.3.2 (the last 1.x and 2,x releases) still run on all platforms that also support 3.4.2, and I have no reason to assume this would change with 4.x

Reply

• Jun 9, 2020 - 13:47

Yes, a short term solution for short term needs to get arround limmitaions earlier in the life of the project. Without development, the downrev version will stop working. Im not talkinging about musescore 4 or even 5. I mean longterm. The first thing to break would be the dependencies. Maybe Ubuntu 28.04 wont be able to run the old version of qt musescore 1 needs to compile. Then its down hill from there

Reply

• Jun 9, 2020 - 13:49

Why would a downrev version stop to work? As far as I can tell this hasn't happend in the past 10 years, my MuseScore 1.3 still run on Windows 7, 8, 8.1 and 10 for example (even if the former 2 OSs are not supported any longer, by MicroSoft)
Yes, 1.3 also ran on Windows XP and Vista and those are obsolete meanwhile, but so what?

Reply

• Jun 9, 2020 - 13:58

Sorry my edit crossed with your reply. I dont know. Maybe the industry switches to arm for the desktop and earlier dependencies arnt available. Stuff happens. There are plenty of people with scores from the early 90's where they cant easily open with modern software. Heck i have scores for the powerpc mac version of melody assistant. I'm boned with a few of them.

Reply

• Jun 9, 2020 - 14:10

Yes things have standadized nicely lately. But i have been burned before. Apple will be Apple, but their switch only happened in the. Mid 2000's. The killing off of 32bit executable could potentailly have caused problems but didnt so far. (Is musescore 1.3 64bit?) Point is, dont be supprised.

Reply

• Jun 9, 2020 - 14:32

"How is that a reason to tell people to spend days to upgrade all V2 scores to V3 right now???
Who does that?"

Indeed im talking about very long term which the suggestion on multiple file formats, not just extensions, effects and makes the updating task more convoluted. Going from V2 to V3 seems a pain. (Try from old xml ;)) I would hope going from v3 to v4 would be better and onward as the project matures.

Reply

• Jun 9, 2020 - 14:34

Whatever, extensions have got nothing to do with all this
And no, going from V2 to V3 is not a pain per se. Many scores cross that border without a hitch. But indeed some don't without some bigger changes to their layout, and some very few don't at all (at least not without changing things I'd rather not change). Same for 1.x to 2.x BTW, and I have a whole set of 1.x scores that I just can't migrate without loosing the entire layout.
Again, completely independent on whether the extension gets change or not

Reply

• Jun 9, 2020 - 14:38

Whatever, extensions have got nothing to do with all this

Well yes extensions have a good deal to do with that.
Because if ( and we both agree that the answer is no ) it is necessary/highly recommended to upgrade all your scores at once from V[N] to V[N+1] when V[N+1] is out, then indeed there is no need to be able to keep a long term distinction in file extensions between V[N] & V[N+1]

Reply

• Jun 9, 2020 - 14:46

Extensions would help a lot.
No, sure not a lot, maybe a little

What a nightmare if there is no quick easy way to know what [N] is...
Opening it will tell you on import (as of 3.x, before there's File > Score properties, not too nice indeed)

As will a decent naming schema, like a separate folders for 1.x, 2.x, 3.x. MuseScore even does that by default.
I'm using this since 10 years.
Folder "Scores" -> for 1.x (at one point I should move those to "Scores/1.x" maybe)
Folder "Scores/2.x" -> for 2.x
Folder "Scores/3.x" -> for 3.x
Folder "Scores/4.x" -> for 4.x

Reply

• Jun 9, 2020 - 15:01

There are pros and cons for changing extension or not. I learned from many lengthy discussions like this one that it will stay like it was all the time.
But one question: would it be possible somehow to show if an MSCZ file is a V2 / V3 / V4 file in windows explorer or whatever file manager is used?
The info is available in the header of the MSCX file:
< museScore version="2.06">
< programVersion>2.0.3< /programVersion>
< programRevision>3c7a69d< /programRevision>
< Score>
or
< museScore version="3.01">
< programVersion>3.4.2< /programVersion>
< programRevision>148e43f< /programRevision>
< Score>
or the like.
Couldn't that be shown in the file properties?
It would make opening the intended MuseScore version significantly faster.
I'm pretty sure it is possible: Right click > properties > details in e.g. windows explorer shows detailed info about .jpg, .mp3 and many other file types. Why shouldn't that be possible for .MSCZ files?

Reply

• Jun 9, 2020 - 16:02

Consider the following (partly imagined) situation and illustration of the problems caused by the change from MuseScore 2 to 3.

Using MuseScore 2 I wrote a perfectly crafted and formatted piece for wind band comprising score + 20 odd parts. I receive a phone call: "I have lost my 3rd clarinet part". Me: "Don't worry, I will print a new one". I blow away the cobwebs from that part of my hard disc and click on the file to open it. MuseScore 3 whirrs into life. Me: "Curses! It is a MuseScore 2 file." At that stage I have the options of 1) proceeding with MuseScore 3 accepting its offer to reset everything to its default positions which produce somewhat but not exactly similar results as my careful manual adjustments made to work around MuseScore 2's shortcomings, or 2) not accepting the offer and seeing my manual adjustments cause MuseScore 3's autoplacement to do many strange and unexpected things. Neither of these options allow me to print an exact replica part straight away - or perhaps ever as I don't remember exactly what adjustments I made to every part of every piece that I wrote using MuseScore 2 and so, without opening in MuseScore 2 I don't even know what they used to look like. Time is pressing. I accept option 1), open the 3rd clarinet part tab and hit print. Then I see MuseScore 3 has made a subtle change in the layout of the part, forcing the final measure before a manually entered page break onto another page. It looks silly there on its own! It is now several minutes past the scheduled down-beat time and I can imagine the disappointed look on the 3rd clarinettists face if I turn up empty handed. So then I go for option 3): Close MuseScore 3; find MuseScore 2 (I haven't used it for ages and don't have it as a desktop shortcut and only keep it for occasions like this), open it and drag the score into it (remember, just clicking on the score again will open it in MuseScore3) and finally print the part looking exactly as it was when I made my final tweaks to slur placements two years ago and just how the 3rd clarinettist remembers it.

How much easier my life would be had the decision been made to have a .mscz3 extension for scores created with MuseScore 3. When I click on a .mscz file it would be associated with MuseScore 2 which can rouse from its slumbers and get on with the job in its old fashioned and quirky way without worrying that smooth talking johnny-come-lately MuseScore 3 at all.

When MuseScore 3 was released, I thought using the same extension for backwards-incompatible file formats was a surprising decision but as it was a done deal, there seemed little point in making a fuss. If MuseScore 4 will allow MuseScore 3 files to be opened without changing layouts even subtly then there is no problem. If not and there is an opportunity to make a fuss about file extensions before the release of MuseScore 4, well here I am making a fuss.

Reply

• Jun 9, 2020 - 23:04

The whole first part of the above has nothing to do with the file format, just about layout changes. So really, it comes down to just the need to either remember it's a MuseScore 2 file (the default location is a MuseScore 2 folder, BTW) and go directly to MuseScore 2 to open it, or if you jump the gun and let it open in MuseScore 3, close it and try again. Not really seeing what the big deal is here, or what any of the stuff of about layout has to do with anything.

Reply

• Jun 10, 2020 - 09:59

No.
You are completely missing the point.
If MuseScore 3 would have displayed MuseScore 2 files (almost) like they were displayed in MuseScore 2, then there would have no need at all to keep MuseScore 2 active on the PC, and therefore no need at all to make distinction between V2 and V3 files.
It is EXACTLY that layout issue that forces to keep both programs and therefore to have a file extension distinction.

Reply

• Jun 10, 2020 - 10:06

Than almost any even minor version needs to have tan extension of their own, it is nut just the major version that change layout.
I quite often have to re-layout my scores, because all of a sudden some measure takes slightly more space in e.g 3.4 that it did in in e.g 3.1 and therefore results in different system and page breaks.

Reply

• Jun 10, 2020 - 14:36

To be clear: it is the file format difference that prevents MuseScore 3 files form opening in MuseScore 2. This is completely unrelated to the score layout differences that causes MuseScore 2 files to look different in MuseScore 3. Ther two literally have nothing to do with each other. That is why we are confused by what is being written here, it seems people are assuming these facts are related when they are not.

In any case, my point was that spending a whole paragraph talking about fiddling with score layout after accidentally loading a MuseScore 2 score into MuseScore 3 is misleading. It appears the intent was to say that somehow one is doomed to doing that because we didn't change the extension. nothing could be further from the truth. Most MuseScore 2 scores look fine, or even better, in MuseScore 3. For those that don't, it takes all of a few seconds to close MuseScore 3 and one MuseScore 2 instead. The post was making it sound like it was an enormous hardship - by talking about all the time spent fiddling with layout - when that time was completely unnecessary.

Personally I'm ambivalent on the extension change. Right now it seems pretty like there would be a file format change to support the new features, so Musecore 4 files would be unlikely to open in MuseScore 3. But it's not a given that were would be many score layout changes. There might or might not, the biggest one I can think of being contemplated would probably be active only for new scores but wouldn't be anywhere near as big as the one from 2 to 3. And in any case I still don't get what's so hard about choosing to open a MsueScore 2 file in MsueScore 2 if you think it's helpful. For many files, it's not, so why force that on people?

Reply

• Jul 13, 2020 - 14:38

> Is the AppImage executable format subject to library dependencies?

It is, but most of the libraries are bundled inside the AppImage itself, so it has very few external dependencies.

> I thought AppImage was fully self-standing and therefore should not become inoperative if a library version is no longer available.

Most libraries are bundled inside the AppImage, but we don't bundle libraries that you would expect to find on any Linux distribution, such as the C++ standard library. Those libraries tend to maintain backwards compatibility for many years (decades in fact) but there is a risk that they will break something eventually, or get replaced by something else, or that we didn't bundle something that we should have bundled. If that's the case then you'd need to run the AppImage inside an old distro (perhaps inside a virtual machine).

Reply

• Jun 27, 2020 - 20:55

I just found this discussion by incident. Two short comments:
1. It might be worth considering that if a file stored with an older (major) version of MuseScore is opened, a backup copy is made automatically. That would prevent to accidentally overwrite the original file.
2. It is always a good idea to have pdf exports of scores, so that a lost part would not require to open the MuseScore file...

Reply

• Jul 1, 2020 - 11:55

If MuseScore 4 can save (not just open) files in MuseScore 3 format (unlikely) then it would be necessary to use a different extension for each format. Otherwise it would just be a convenience and I don't really care either way.

An option for those of you who keep files in both formats is to include the version number in the file's name rather than the extension:

  • My_Score-2.mscz (MuseScore 2 format)
  • My_Score-3.mscz (MuseScore 3 format)
  • My_Score-4.mscz (MuseScore 4 format)

Putting the number in the name rather than the extension has the advantage that it will not be hidden on Windows. We could even provide an advanced option in MuseScore to save files this way by default.

Reply

• Jul 13, 2020 - 05:17

I am one of those still using MS 2.3.2 to originate scores. I will occasionally import a MS2 score into MS3 just to generate a synthesizer output and take advantage of the single-note dynamics in MS3. In this case I use a variant of Shoogle's approach of including the major version number in the filename, but I follow it with an "x" (e.g., -MS3x.mscz) to indicate that the file is a raw import and not a fully formatted MS3 score. In cases where I have imported a finished MS2 score to MS3 and reformatted it, I use "-MS2.mscz" and "-MS3.mscz" in the file names to distinguish the two finished versions.

Reply

• Jul 23, 2020 - 00:02

I will add my two cents, if it hasn't been mentioned before ( I am not reading 70+ comments to see if it has been mentioned already). IMO, if Musescore 4 is downward compatible (V4 can open V3 files), then keep the same extension. If an old version cannot be read in the new version, then the new version needs a new file extension. YTF would you care if you open your V3 scores in V4 AS LONG AS V4 keeps the same formatting. Uninstall all your old versions - I do. However, that is definitely something the programmers need to ensure - V4 keeps the same formatting of V3 scores.
I know Word does when you save the file. Word incorporates new formatting features into the old version files, BUT when you save, it takes out the new features (if you want) so the formatting stays the same. Musescore/Finale/Sibelius are just wordprocessors for music so lets have the same features as wordprocessors.

Reply

• Jul 23, 2020 - 00:37

For me, the question is whether V4 will keep the formatting of V2 files - something V3 doesn't do. Or what about a separate program to do nothing but up-convert files from one version to another, keeping the formatting? As for file extensions indicating the version, I'm in favor.

Reply

• Jul 23, 2020 - 00:42

It’s too early to say what formatting improvements will occur automatically versus which you might need to opt in for, or how existing scores might be affected. But I would it’s pretty unlikely that anyone would be trying to reimplement the old MuseScore 2 layout algorithm. It will almost certainly continue to make sense to keep that around for those older scores you don’t wish to update.

Reply

• Jul 23, 2020 - 04:45

Last time I tried to do any work in MS3 I felt as if the placement algorithm was always trying to second-guess me about where to put things. It would push the bottom staff of my scores off the page in order to space out the staves to resolve collisions, which I never asked it to do. I started a thread on this topic which went on for a long time, and I'd rather not go through the issues again. I suppose there are workarounds for most of the situations I described, but in the end I decided to stick with 2.3.2 where it at least feels as if I'm working on manuscript paper and I'm in (essentially) complete control of placement. I also had an issue with the pianoroll editor, to be able to (1) specify a cutoff advance as an absolute time interval rather than a fraction of the note duration and (2) have this apply to all notes in a selectionof measures within a staff. This also went through a long discussion in which I felt that my original "ask" morphed into something completely other.

I have another suggestion: why not split MS into a suite of individual program modules with a common library, to avoid possible code bloat and still provide a range of functionalities? For example, the search function could be a separate module; format up-conversions similarly; possibly even the MS2 and MS3 placement and layout engines could be library modules so either one could be selected as the user chooses.

Reply

• Jul 23, 2020 - 05:34

I would encourage you to give MuseScore 3 another shot. We actually implemented practically all the suggestions made Olin that thread and then some. I think you will be amazed at how powerful and flexible it has become. So it’s trivially easy to keep the advantage of autoplace overall but have it allow collisions between different staves as MuseScore 2 did, for example. Elements can be moved freely without the need to disable autoplace while still allowing it to work normally otherwise, and lots of other possibilities that make getting layout far easier that what you are having to do with MuseScore 2. And we’re always happy to help you take advantage of all this power and flexibility.

Anyhow, as I said before, it is unlikely that MuseScore 2 scores will import better into 4 than they do into 3. But I would also say, there is enough chance some rework could be needed for some MuseScore 3 scores that I wouldn’t bother updating older scores at this point just on the hope that it eases the transition. I would instead give the same advice as always: for any MuseScore 2 scores that would require significant work to update, leave them there, and use MuseScore 3 to get much better results with much less effort in new scores. The savings in time and effort will from the added power and flexibility of MuseScore 3 will easily outweighs whatever small learning curve you encounter. The fact that these MuseScore 3 scores will also import into MuseScore 4 better than MuseScore 2 scores would is just icing on the cake.

Reply

• Jul 23, 2020 - 06:32

Marc: Thanks for the prompt reply, and I appreciate your positive response. I would be open to trying MS3 for my next score and finding how to work with it. BTW, one positive feature of MP3 that I have already made use of is the single-note dynamics in the synthesizer; for this I have even imported MS2 scores without doing any reformatting, just to export MP3's.

I still have the issue with the pianoroll editor, and I would be immensely thankful if this could be resolved. I've even thought of modifying the code myself; I have the C++ skill but the investment of time needed to learn a new body of code, plus having a day job, has deterred me so far.

Also, what about my suggestion of breaking out functional parts of MS as separate modules, all with a common library?

Reply

• Jul 23, 2020 - 18:14

I don't use the pianoroll editor myself and don't have much insight into its operation. I gather something was changed recently to allow certain edits to multiple notes, but I don't really know the details. See #279210: Cannot change properties of multiple notes in piano roll editor but I can't tell you more than what you see there. I don't think anything has changed regarding absolute offsets. This wasn't different in MuseScore 2, though, was it? As far as I know the units have always been in 1/1000's of the duration. But I imagine this is the sort of thing that will be looked at again as part of the major changes being proposed for MuseScore 4.

Meanwhile, a plugin could probably be written to do whatever sort of special purpose adjustments you are trying to make - these properties are all available. In fact, there are already plugins to do this in general, if not optimized for your specific use case (which I don't totally understand). Probably a two-line change to the DockArticulate plugin, for example, would allow units to be specified in something like MIDI ticks (1/480 of a beat) then converted to percentage automatically.

The general idea of factoring the code out to be more modular is already under way for MuseScore 4, but it's not clear if this is exactly what you had in mind, or what the advantages would be of your model versus what is actually the case. To me, the main goal is maintainability of the source, but I'm not sure I see any direct obvious benefit to the user beyond just having developers able to be more productive.

Reply

• Jul 23, 2020 - 21:03

Pluygins work with AppImages, yes, that's the easy part.

The documentation on how to create them is a bit spotty but it has improved quite a bit over the years. Often your best bet is to start with one - like DockArticulate - that already does 95% of what you need, then try to figure out the rest by looking things up in the documentation that does exist. See for example the Help menu in the Plugin Creator within MuseScore, which takes you to https://musescore.github.io/MuseScore_PluginAPI_Docs/plugins/html/index…. See in particular the Classes pages.

Reply

• Jan 11, 2021 - 20:54

How about this — when MNX stabilizes, MuseScore should abandon the MSCX and MSCZ formats altogether (like how Finale abandoned their MUS format). The upshot is that the MNX format, unlike the MSCX/MSCZ format, will have a fully-featured specification, which will allow rookie developers to add new features to the MuseScore app more confidently, without having to painstakingly reverse-engineer the file format. Unfortunately, I don't foresee this happening until at least MuseScore 5 or 6.

Reply

• Jan 11, 2021 - 21:05

I don't see this happening at all, not for MuseScore or for any other notation program. MNX may be great as a way of capturing semantic information about music in a way that all programs can import and export, but I see no reason to believe it would ever be suitable for use as the native format of any program. That's because any sort of truly robust native file format needs to accurately represent the internal data structures of the individual program,. and every program has its own unique internal representations.

I suppose a program could be written from scratch in such a way that its data structures do reflect MNX. But my prediction is MNX has no more chance of being adopted as the native format for any existing major notation program than Esperanto does of being adopted as the official language of any major nation.

In any event, it's mostly moot. The lack of documentation of the MSCX format is not really any sort of deterrent to anyone wanting to add features to the program. The hard part of development is learning the code organization, algorithms, and data structures we use and where new features would fit. If the feature happens to also involve needing to read or write the file (only a small minority of new features do), figuring out the details of how to write them to the file format are trivially easy in comaprison.

Reply

• Jan 12, 2021 - 16:29

(following up also on the comment from @jeetee)

To put this in practical terms - generally working on the code requires zero knowledge of the file format, because you are working on the data structures directly. So, for instance, changing something about how fermatas are displayed or played back requires zero knowledge of how those fermatas will eventually be written to the file or read from it. Even if you add a new property to an element, you need only add a call to writeProperty() or add the property to the list of style properties, and the reading and writing gets handled for you. It's extremely rare to need to delve into the details of the XML. I've been contributing for almost 10 years now, with over 100,000 lines of coded added, and I'd be surprised if a dozen of those lines relate to any other detail of the file format.

Reply

• Jan 12, 2021 - 17:42

I also don't think that we will use MNX as our native format. MusicXML, the predecessor of MNX, lacks certain features that mean it is not suitable as a native format (this was a deliberate design decision to ensure the open format was not a threat to commerical software), and it's not clear that MNX will gain those required features.

While MNX was originally proposed as a way to solve limitations in MusicXML, I get the impression that the community is reluctant to deviate very far from MusicXML (or at least they cannot agree on how best to do so). Examples are the descisions on how to encode pitch in MNX (they used written pitch rather than sounding pitch) and how to encode beams in MNX (the start and end points are stored explicitly for each beam; there is no option specify high level beaming rules like in MuseScore's Time Signature Properties). Both decisions mirror MusicXML, and both decisions make MNX unsuitable for native use by programs like MuseScore. (The decisions are good for transcription software but not for composition software, and while MuseScore is used for both purposes, it is primarily a composition tool.)

Reply

• Feb 10, 2021 - 22:22

The drama surrounding something as dead simple as the naming of MNX (Common, Generic, etc.) is a pretty good indicator of the challenges the MNX project faces.

There are some extremely talented and capable people working on the project, some of the best in the industry, but the way the effort is structured allows for far too many compromises.

To the point, not only does this make the MNX painfully slow, but if it ever actually becomes stabilized it will have compromised so much trying to cover far too many use cases that it would be absolutely impractical for software that is distributed on the scale of MuseScore to effectively implement.

Also, the MuseScore file format is free, open, and is rapidly evolving in comparison. It would make far more sense for other software vendors to use as a standard file format vs. MuseScore adopting MNX.

The fact that there are already millions of scores publicly available in MSCZ format further strengthens the argument for MuseScore file format as an industry standard.

Reply

• Feb 1, 2021 - 06:46

I don't think the current file format (extension?) has something bad: it does it job fine enough. The only real problem, as you said, is the migration of the scores from an older to a newer Musescore (1-2-3etc). I don't think there have been REALLY major changes in the code of Musescore and the fundamental way it functions to actually have the need to change the extension. The migrating problem can be fixed through other ways, but changing extension is probably one of the most unnecessarily painful ones... perhaps.

If musescore 4 has really major changes, perhaps a new extension could be great? But maybe there won't be any great alterations in the code? I don't know. But I think that's the reason there is no need for another extension.

Also, changing to a proprietary one is a total no... at least from many in here I believe.

Reply

• Feb 10, 2021 - 22:35

A new file extension for MuseScore 4 is a very impractical and messy solution for a temporary problem.

GuitarPro is a good reference for this approach, having changed extensions with major releases. There have been considerable user challenges in juggling various versions and file extensions.

The better solution is to improve ability to convert files to newer versions.

Much of the reason for wanting to preserve files in previous versions is due to the considerable manual effort involved in formatting of layout and engraving.

The long term goal is that automated layout and engraving will be better by default than the manual efforts in previous versions. Once a reasonable level has achieved with these automated defaults, this issue is greatly reduced if not entirely resolved.

Reply

Do you still have an unanswered question? Please log in first to post your question.