Are versions 3.3.x-3.5.x no longer available in Linux AppImage format?

• Mar 30, 2021 - 05:08

I needed to fix a typo in a score that was last edited with a 3.x version prior to 3.6. Unfortunately I had deleted the earlier 3.x executable when I upgraded to 3.6. I tried loading the score into 3.6.2 but found a lot of my custom positioning - hairpin heights, mainly - different from the way I had left it. So I went looking in the repo for the earlier version, but the latest 3.x I saw there in x86-64 AppImage format was 3.2.3. Odd because the Windows repo appears to have 3.3.x thru 3.5.x. Is there a reason these were removed from the Linux AppImage repo?

I know the rendering was upgraded from 3.5 to 3.6 and this may cause things in earlier scores to migrate. But I hope it doesn't mean that every time there's a significant version upgrade (e.g 3.5 to 3.6), my earlier scores have to be re-edited in the new version. (Moral: Every time you do a score with lots of custom positioning, SAVE the MS executable in case you need to reload that score!)


FWIW, you shouldn't be seeing those sort of differences. We improved some defaults in 3.6 and added some new capabilities, but we also set things up so that older scores continue to use the older defaults and the new features are disabled. So you shouldn't see any visible differences aside from those resulting from outright bug fixes. If you attach one of the scores in question and describe what seems to have changed, we can investigate.

In reply to by Marc Sabatella

Marc: Thanks for your interest and the prompt response.The attached score was last saved in 3.3.4 after positioning all elements. The two screenshots show one conspicuous difference at around measure 366 between opening the score in 3.3.4 and in 3.6.2. Note that the page breaks also seem to have moved.

Opened in 3.3.4 (correct positioning)

Opened in 3.6.2


Attachment Size
Screenshot334.png 16.19 KB
Screenshot362.png 16.62 KB

In reply to by dhfx

Hmm, this score contain a number of problems that would have been issues in any release. In particular, there is a -3.0 sp horizontal offset built in to the dynamics text style, so dynamics appear way to the left of the notes they are attached to, And then the hairpin in question has automatic placement disabled, thus allowing it to collide with dynamics positioned in this way. You can see exactly the same happen in 3.3.4 if you simply add a system break somewhere so that hairpin is on a single system instead of split. As for the "detached" text, it is actually attached to measure 370 and then dragged almost 42 sp to the left to appear as if it is in measure 366, but this too breaks if the distance between measures 370 and 366 changes, as happens if the location of the page breaks changes. So again, you can induce the same problem in 3.3.4 by, for instance, placing a break after measure 360.

Anyhow, while the problems are thus really inherent to the score, the reason you see a difference here is that 3.6.2 seems to be able to fit measures per page than 3.3.4 did in a couple of places, thus changing the system break locations. Notice measure 336 is on page 64 in 3.6.2 but 67 in 3.3.4 (well, I don't have that version, I'm actually comparing against 3.4.2). There were a few bug fixes involving things like the amount of space after an initial clef when using the open/atonal key signature - previous version generally added too much. Just a fraction of an inch too much, but on some pages of your score, this was enough to cause older versions to fit fewer measures on the page that it should have.

Page one is one such example right off the bat - look at the very first measure and see the extra space between the clef and time signature in 3.3.4? That was the bug that was fixed. 3.6.2 closes this gap to what it should have been all along. The difference is enough that 3.3.4 can only fit six measure on the page, but 3.6.2 can fit seven. A handful of other pages with a similar discrepancy, and that's how things got off.

In this case, there's a pretty simple solution if you don't feel like fixing all the places where there are inappropriate manual adjustments like the -42 sp offset on the text or the disabled autoplace on hairpins, etc. You could open the score in 3.3.4, run Format / Add/Remove System Breaks, and choose the second option - too add breaks right where they are. This basically locks this layout in, so even though 3.6.2 could fit more measures on some pages, it won't. You end up with measure 366 being right where it was in 3.3.4, and all looks good.

Still, long term, probably worth eventually fixing the core issues there, to make the score less "fragile" - so occasional changes to where the breaks occur don't mess things up. At least those two issue (the disabled autoplace on the hairpin, the bad offset on the "detached" text). You might consider also choosing a more conventional placement for dynamics - directly below notes rather than far enough to the left to invite collisions. If any specific markings need to be adjusted horizontally to avoid the need for extra space between staves or whatever (that's not uncommon), they could be adjusted invidually instead. But, that in itself isn't causing the problem, so that would be optional.

In reply to by Marc Sabatella

Marc: Thanks for the detailed analysis. By way of explanation, the horiz offset on dynamics is simply a personal preference, and there have been a few other instances where I saw no alternative to using large offsets, e.g. at the end of a hairpin where the dynamic had to be pulled across a system break to "appear" in the right place. And thanks for the suggestion to freeze the layout by locking the system breaks.

There were also a few cases (which I forgot to mention) of hairpins being shifted vertically from where I had placed them manually. I am still transitioning away from MS2.3.2 and my inclination is still to do all the positioning myself until I have more of a feel for the auto-placement features of MS3. (I confess to perhaps being still a bit traumatized by my first experience with MS3 when I found it was pushing the bottom staff of my score off the page in order to resolve collisions further above.)

In reply to by dhfx

It was an interesting issue to consider, so I'm happy to have had the opportunity to look into it! FWIW, I still assume the large offset in question on that particular text was a simple mistake - it's literally several measures away from the correct location. Offsets within a measure can definitely be needed for various reasons, but it would be incredibly rare to need to move something several measures, and I'm defintiely not seeing it here.

I remember your consternation regarding the staff spacing! From one of the very early 3.0 releases, there was a style setting "minimum vertical distance" that could be set negative to prevent the space and thus allow collisions, but I think it wasn't exposed in the UI until a bit later. Based on feedback from you and others, we ended up adding quite a few more controls, like "=" to toggle automatic placement element by element (which also should not needed that often but can occasionally be useful). Also things like the per-element "minimum distance" and the automatic management of this so you can drag or otherwise move elements just about anywhere - including onto the staff or into direct collisions with other elements - without disabling autoplace.

Obviously, you know about most of these, but you might not be aware of some other changes in 3.6 that might make your life easier. One is, you can now set a crazy small minimum staff distance, and MsueScore will add space as needed to fill the page, thus allows pages to come to the same bottom margin even where there hidden staves on some, or extra space needed for various markings on some.

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