[ branch ] R5475 stem issues
I was going through the demos and noticed that two of them (golliwogg and inv6) displayed extremely long stems for some beamed notes, both starting on page two. I don't know if this is a regression, or simply that the files are older versions.
As an aside, why are most of the demos in MSCX instead of MSCZ?
| Attachment | Size |
|---|---|
| clp200.png | 18.24 KB |
| clp201.png | 42.72 KB |
Comments
Note that selecting the beams and doing a Ctrl-R will restore them to their proper height. Once done and resaved in MSCZ the issue is gone.
Can you check the revision number?
See this , perhaps.
They were 1.10 and 1.12 if I remember correctly. I see Lasconic has updated these and a few other demos in 5460 to 1.14. Why the others were updated I don't know as some of the other demos are still in quite old versions. For example, PlanxtyCarolan is 1.9 (1.09) and sonata16 is 1.10. I do still wonder why most are stored in MSCX.
(PS: Is it possible to view an MS file revision number in the branch?)
Reply to the PS: Yes, with the version number plugin
Edit: No, it doesn't work in prerelease 2! I'm sure it did in prerelease1 though?
Edit 2: it does work, but not on these old scores, apparently, I tested with golliwogg.mscx
I was hoping for something "factory", built-in to MS. I've never added any plugins yet. for now, I send the MSCX file to Notepad. MSCZ files must be extracted first, then sent to Notepad.
indeed I fixed the offending files. Demos are in different formats, of different versions of MuseScore, so new users can see MSCZ and MSCX exist, and be curious :)
More seriously, if they work, it's ok. We will update them all in 2.0.
But doesn't fixing these specific files gloss over the issue that backwards compatibility is becoming more problematic, even in the trunk? I assume these files worked OK in 1.0, but they did show some problems in 1.1 and showed more problem in 1.2. Shouldn't compatibility issues be fixed?
What are people going to do in the near future with the many older pre 1.0 score files if the branch no longer loads them cleanly or fails to support them at all?
There are demos files, not regression tests. As many software we can't keep compatibility for ever if we want to add features and fix bugs. MuseScore 1.0 files should be open without degradation by MuseScore 1.1 and MuseScore 1.2. Musescore 2.0 will open MuseScore 1.2 correctly but for 1.1 and before, it will be better to pass by 1.2. The main difference here, compared to proprietary software, you can still download old version of the software to make the conversion, and for free. You can even get the code and recompile it if needed.
I meant the revision number of the branch - 5475 doesn't exist.
That was one of my thoughts a while ago - I think all demos and templates should be refreshed for every release (from 2.0, that will apparently happen). It might be best not to use a template, if it was produced in an older version?
At the time, 5475 did exist. What I am doing now is using the SVN option "Update to revision" and entering the last checkin number for either the bracnh or trunk and not simply doing an SVN update to the latest number. This way I have the correct branch or trunk version, instead of one that could be out by several checkins. The branch and trunk can never be the same checkin version.
Lasconic, I think you misunderstood my comments. The demo files are supplied with the install, and if they cannot be accurately opened by the existing branch version, then either the branch has a compatibility issue and it should be fixed, or the files were damaged. Which was it in this case?
This begs the question (and I know the answer is somewhere on this site): what are the file revisions for the various versions of MS 1.x?
http://musescore.org/en/developers-handbook/version-information
Automatically closed -- issue fixed for 2 weeks with no activity.