The Future of Series 2
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
Comments
Could we add such criteria (and sections) on that page? Also a link to this topic so additions can be discussed?
In reply to Could we add such criteria … by chen lung
I thought there was a 2.2 hit list (items to be addressed if version 2.2 gets released) but I can't find it.
In reply to I thought there was a 2.2… by mike320
See https://musescore.org/en/developers-handbook/musescore-22-hit-list
In reply to I thought there was a 2.2… by mike320
It was linked in my post ;)
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 Most of these are already… by Marc Sabatella
I suppose the aim of my post was giving a sense of reason and focus to any continued development of series 2, but yes, I plan to post specific issues soon.
In reply to I suppose the aim of my post… 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:
In reply to I suppose the aim of my post… 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.
MusicXML:
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.
Soundfont:
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 I just wanted to say firstly… 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.
In reply to I just wanted to say firstly… by chen lung
So far the code in got master has functions to read 3.x, 2.x as well as 1.x files, and I don't see why that should get removed. However, the rendering will be different.
The plugin framework is going to change and improve.
In reply to So far the code in got… by Jojo-Schmitz
Good thread.