MuseScore
MuseScore copied to clipboard
musescore
[MU4 Task] Changes to consider when updating the file format
We don't get the chance to make breaking changes to the file format that often, so when we do get such a chance, we should fully utilise it. Therefore I thought it would be good to build a list together of things we would like to consider changing.
- [ ] Rename the
instrumentIdproperty tomusicXmlId, which is far more accurate - [ ] Maybe things necessary for "not-yet-fully-created" parts, see #15546 (comment)
- [ ] Maybe: write the main mscx file under a fixed filename inside the mscz. Would probably have prevented the two "peculiar cases" in #15739. Disadvantage: possibly less convenient for uncompressed folders.
- [ ] ...
@igorkorsukov @shoogle @mike-spa I thought I'd quickly mention you, so that you know about the existence of this list, since you doubtlessly have ideas about this too.
Assigning this to the 4.1 project, since 4.1 will be the first chance to make changes to the file format.
See also https://musescore.org/en/node/296654 (you need to be logged in to MuseScore.org to see the "What links here" list).
(Despite what I wrote on that page, I think we should consider allowing breaking changes to the file format on minor releases. Just doing it on major releases will probably prove too restrictive for us.)
When the file format changes, what about changing the extension ?
In GuitarPro, when they change the file format and broke the ascendant compatibility, they change the extension name. E.g. Guitar Pro 4 => .gp4 , Guitar Pro 6 => .gpx, Guitar Pro and beyond .gp
Furthermore, they include and export mechanism to the previous formats.
Working with MU with other people is a hell. Between the ones using MU4.x and the ones sticking to MU3.6 (and there are numerous), the collaboration is complicated. Especially, when the file extension doesn't tell if the file has been saved in MU3.6 format or MU4.x format.
The consequence, in our music group, is that everyone must keep using MU3.6.
When the file format changes, what about changing the extension?
FYI, we no longer preserve compatibility between minor releases.
The consequence, in our music group, is that everyone must keep using MU3.6.
You would have to do this anyway, at least for your shared scores. Changing the file extension wouldn't allow MS3 to open MS4 scores.
they include and export mechanism to the previous formats.
We could allow you to save in the older format like Guitar Pro, but that would be a lot of effort to maintain considering that MuseScore is free to upgrade, and we already have (some) compatibility via MusicXML.
You would have to do this anyway, at least for your shared scores. Changing the file extension wouldn't allow MS3 to open MS4 scores.
For sure, but I would ease the process of detecting what is the version of the file you are receiving. And it would help the OS opening the right program. A .ms3 extension being associated to MU3.6/3.7 and a .ms4 extension being associated to MU4.
This constant censorship here on GitHub is unacceptable, esp. on perfectly valid and on-topic remarks
I've now mentioned this issue here in all my PRs for the 3.x branch of my fork that made the backwards compatibility (Mu3.7 being able to read Mu4 scores) possible. No rocket science nor black magic involved.
Sure, it's possible, but the scores won't look or sound the same in MuseScore 3 so it's not worth the effort considering that the upgrade is free, you can run both versions side-by-side, and MusicXML is available for those who really want to use the older version. Also, we plan to change the format on minor releases, so backporting would be an ongoing effort rather than a one-off thing that would work for all MS4 scores.
won't look or sound the same in MuseScore 3
Reading many answers from the core-MU4 team, I've the feeling, that the look of the scores and the audio rendering are what rules everything in the priorities.
Indeed, having good-looking scores is important. And the good audio rendering is interesting. But they are not all.
Not all users are copy-writer aiming at scores with the top-of-the rock engraving.
Many users are also teachers, composers. For which the ease of use during their composition process is of equal importance (and even higher importance) than having the perfect distance between beams.
For some of these users, MU3.6 or MU3.7 still remain of better-value: many plugin don't work any more on MU4.x, they are a lot of things no longer working in MU4.x.
I don't criticize the priorities made by the team. But I just feel like you are not respecting or under-considering the part of the community using MU3.6/7 and that will stick to it until those "regressions" are fixed.
This constant censorship here on GitHub is unacceptable, esp. on perfectly valid and on-topic remarks
This is not the place to constantly advertise your "3.7".
This is not the place to constantly advertise your "3.7".
I don't agree. This MU3.7 is a good solution that fills the gap between MU3.6 and MU4.x. It is this kind of missing link that allows both users, the ones preferring the MU3.x versions (see my previous post) and the ones preferring the new stuff of MU4.x, to collaborate together.
The other option, is everyone back to MU3.6.
So, you shouldn't under-estimate the benefits of MU3.7 for MU4.x.
What bothers me about "3.7" is that it seems a (protest) action against the development of MuseScore, instead of something to support MuseScore. Instead of advertising 3.7, you could also advertise 4.x to those staying on 3.x, and instead of developing 3.7, you could also have put your time in making useful contributions to MS4 that fix the reasons for staying on 3.x.
(Before everyone gets very angry, let me make clear that I understand that all your ultimate intentions are surely good; but it's just about how the "3.7" project comes across on me.)
This is not the place to constantly advertise your "3.7".
OK, so for you mentioning it once (in this tread, once in another) is constantly... interesting. It isn't advertising either, it is pointing out the possible options.
What bothers me about "3.7" is that it seems a (protest) action against the development of MuseScore instead of something to support MuseScore,
No, it just tries to fix things that the core team hasn't been able and willing to fix. Yes, it is the result of having been ignored/neclected for way too long. It is not a protest agains Mu4 at all, but a protest against the lack of an official Mu3.7, possibly driven by the community rather than the core team. My work on the 3.x branch started after 3.6.2, but long before 4.0.0.
Instead of advertising 3.7, you could also advertise 4.x to those staying on 3.x,
I can't currently, with good concious, recommend the use of Mu4 do anyone in my vincinity, like in our choir, as there are too many things still lacking in Mu4, for too little benefit for our use case. We e.g. use channels to separate Soprano/Alte and Tenor/Bass für playback of closed scores, not possible in Mu4. This is the 1st major realease this happens to me, I've started using and recommending Mu2 and Mu3 very soon, like with 2.0.2 and 3.0.2 or the like and never looked back to the older version, except for very minor changes in my older scores. Meanwhile Mu2 is completly out of use for me, everything but one songbook which is still on Mu1 is now on Mu3.6. I'm a version junckie, I'll get on to the newest version as soon as I possible can. That I haven't yet switched to Mu4 (is supposed to) speaks volumes, it is just not the right tool for my needs currently.
and instead of developing 3.7, you could also have put your time in making useful contributions to MS4 that fix the reasons for staying on 3.x.
That's not fair at all, do you want me to go and count all my PRs against master since the split from 3.x?
I would have liked to see an official 3.7 a year or two ago, but we are where we are. Time spent developing 3.x now is time wasted.
For some of these users, MU3.6 or MU3.7 still remain of better-value
Indeed. I'm still using 3.6 for a couple of projects because it has features that haven't yet made it to 4, though the gap is narrowing, or rather growing rapidly in the other direction (4 has many, many features not available in 3).
I'm using 4 for all my new projects. I keep the scores in different folders so haven't had compatibility problems. However, I can see that this would be an issue when sharing scores with other people, so perhaps we should think about versioning the file extension in future releases.
We wouldn't do it for minor releases because we can generally expect people to upgrade pretty quickly. But for major releases there will inevitably be some side-by-side usage, and we even support that scenario explicitly, so perhaps it does make sense to version the file extension for major releases.
Of course, there still wouldn't be any forward compatibility between major or minor versions.
I would have liked to see an official 3.7 a year or two ago, but we are where we are. Time spent developing 3.x now is time wasted.
Not quite true, at least doesn't match my recollections, it was you (too) claiming that 3.6.2 would be the last 3.x ever, not even a 3.6.3 with a handfull of the most urgent fixes was never really considered.
Whether, how, where, when and why I waste my time is my business alone, and with a couple users finding my work on a 3.7 worthwile (check the forum), I don't feel my time being wasted there.