The Future of Series 2

• Sep 22, 2017 - 13:24

Series 3 could be the pinnacle in some regards (e.g. layout), but it won’t be available, nor stable for a while, and whilst I understand there’s reluctance to continue it, I think 1-2 years could bring series 2 to a conclusion and it will also help 3 (just as 1 helped 2), so modest improvements towards this matured series will help. I don’t seek new features, but rather, fixes (or addressing) within parameters/boundaries that avoid further issues. There is currently a list, but I believe there could be more. Here is my suggested criteria:

• MusicXML import/export: For general function and testing (e.g. OpenScore - braille; Audiveris)
• Bugs (e.g. corruptions; crashes; nuisances)
• Improving transition between major versions (making non-openable-in-3 files suitable in 2; minimising revisits; addressing regressions)
• Accessibility
• Implementing typesetting features/elements (e.g. those in MusicXML)
• Soundfont
• Translations
• Compatibility and compliance with operating systems and vendors


Most of these are already being addressed, at least in some general sense. If you have a more specific list of issues - like actual issues with tracking numbers - that would be useful to see.

Realistically my sense the main focus for 2.x will remain fixing critical bugs and adding whatever new features originally implemented for 3.0 that happen to be easy to add to 2.x without breaking compatibility. But most new development would continue to target 3.0.

In reply to by chen lung

Do you imply that the current 2.x serie lacks a sense of reason and focus? :-)

Any new feature in 2.x should be compatible with previous versions, or you end up in the same place than between two major releases. So this probably rule out most "typesetting features/elements", except if you have actual list for this?
Then point by point:

  • *MusicXML import/export: what's wrong specifically here?
  • Bugs: sure, see the hit list, please file a bug for any meaningful crash or corruption and let's see if it's worth to add them in the list. Some crashes might be structural and rare, so it's not worth to fix them and destroy compatibility.
  • *Improving transition between major versions *, I don't understand, we already do our best to have MuseScore 3 importing MuseScore 2 files. Do you have anything specific?
  • Accessibility, Translation, Compatibility with OS. Again, I don't see what we would lack anything in 2.x currently. Accessibility is being worked on. Translation flow is under control and translators are still busy working on 2.1. When 2.2 is near release, we will switch, like we did in the past.
  • Soundfonts. Again be specific, there is already an upgraded fluidGM_mono version for 2.2.

In reply to by chen lung

Perhaps a fair way to summarize this is to say, the reason for continued development of 2.x is to get critical bug fixes out to user sooner than would be possible if waited until 3.0 was stable enough for release. The focus then is on increasing stability - fixing bugs and not breaking compatibility (or breaking anything else for that matter). It's also important that work on 2.x not delay the release of 3.0, which in turn implies that to the extent non-critical fixes make it in, it would be only those things already implemented for 3.0 that are easy to also add for 2.0 (and thus not delay the release of 3.0) without risking stability (and thus violating the focus of continued 2.x development).

That to me is the "sense of reason and focus". it does mean it's unlikely there would be much in the way of improvements to notation (aside from bug fixes) because that tends to affect compatibility. Usability improvements might seem safer, but they often come at a cost with respect to documentation and that needs to be considered as well.

I just wanted to say firstly, that I appreciate the updates given to the series.

The point (about giving a sense of reason) was so that you don’t think I’m asking for a direction-less continuation of the series without end. By suggesting the criteria/targets, I’m hoping it’ll better-motivate everyone in achieving these goals.

Regarding back-compatibility, I had my views in another topic.

I wanted to ask: How good is the plug-in framework? Having these would speed up my work, allowing more test cases, etc.


Many of my scores (typically band) have some differentiation. Hopefully I can make these known soon.

Transition between major versions:

I’ve since been told otherwise, but I read a while back that series 1 files won’t be openable in 3 (fuelled by the fact it recently resulted in crashes). Were it the case, I would need to open series 1 files in 2 and save them (in order to open them in 3); this won’t be convenient for those with a large library (and I follow a remastering process, though doing hundreds will take time).

Plus, there might be teething issues between 2 and 3.

Typesetting features/elements:

This is one example.

MusicXML’s website (examples and the index) may help us identify anything we could be missing, or not adhering to.


See this.

Translation, compatibility and compliance:

There is indeed no problems I can think of); it was just part of the suggested criteria.

In reply to by chen lung

It's still not clear to me how much, if any, of what you are posting here is intended to be a specific request of some kind.

If you have specific requests, I'd suggest starting new threads, one per topic, with specific examples of something you'd like to see in 2.x that is not already there. Otherwise, it isn't clear what you are actually wanting to happen differently.

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