3.0: Manual positioning of many elements not retained

• Dec 28, 2018 - 14:01

This score I have created with MuseScore 2.3.2 on Windows 10:
MS2.png

When I open it in MS3 and don't reset the positioning, text and line elements are positioned differently:
MS3-dont_reset_pos.png

If I choose to reset positioning, things are not better:
MS3-reset_pos.png

I expected manual positioning to be retained, at least... and automatic positioning to work better...


Comments

hmm...well this is too bad. can you share the score so we may inspect. Even if it is just these two initial measures.

There are still plenty of glitches with autoplacement and import, unfortunately.

In reply to by faben70

Assumption: manual adjustments of some elements not respected by the automatic placement.
Try right-click a fingering, select all similar elements;
Open Inspector uncheck automatic placement.
But many other elements will not respond in the same way.
I'm afraid I can't help you better.

In reply to by Shoichi

I remembered trying unchecking "automatic placement", but I did it again and for fingering texts it restored my original positioning. Thanks!

The same is not true for the lines... the descending line that can be seen over the last two notes of the first bar, just to the right of the "bow up" symbol: MS3 places it on the next measure, but if I move it it's still correctly linked to the G in the first bar. Disabling automatic placement for those lines leaves them to their far-away positioning given by the MS3 import procedure.

I have also opened another thread, here:
https://musescore.org/en/node/280800

where I'm asking if there is a way for a text style to be defined so that text is always placed above or below the note it's linked to, and outside the staff. This means that I wouldn't have to position manually each and every fingering number...

Because it's a major version change and the default layout has changed a lot, it's not going to be the case that manual adjustments can be retained. Or more particularly, they are retained if you don't accept the reset option, but won't look the same, because they are applied to different defaults. That's just the unavoidable results of the layout improvements made. If you have score with many manual adjustments and the reset option doesn't provide the results you want, best to keep that particular score in 2.3.2 for now, then when you have time, re-import it, accept the reset, and reapply whatever manual adjustments are still needed.

In reply to by faben70

As you must be aware from your personal experience, then, it is extremely hard to make improvements as dramatic as we made from MuseScore 2 to MuseScore 3 if we have to continue the support the old file format and layout algorithms. Obviously, it is technically possible, but those are programming resources that could be spent developing new features, fixing other bugs, etc. It's a tradeoff, and both are valid development choices. Luckily, you can keep both versions installed, so that's a perfectly valid option as well.

In any case, MuseScore is open source, so you are welcome to contribute your programming talents to reimplementing the MuseScore 2 layout algorithms for compatibility, if that is what you value most! As say in the open source world, scratch your own itch...

In reply to by ericfontainejazz

Yes, it reveals that "thanks to the hard work of the Inkscape team" the bug was fixed. Apparently, people in the Inkscape team weren't thinking that it was an unavoidable results of the layout improvements made. Apparently, people in the Inkscape team valued the work done by its user base as well as the work they made themselves.

Yes, I could spend some time fetching the MuseScore sources, setting up a development enviroment, understand how MuseScore is designed, where I could improve the import behaviour. I could.

In reply to by faben70

It's doubtful Inkscape has ever made such earth-shattering improvements to layout as MuseScore 3 does. Small tweaks are easy enough to support in a compatible fashion; complete redesign of layout to make things possible that fundamentally couldn't be done before is another matter. If we had twice the number of programmers volunteering to work on the proeject, sure, we cod continue to support twice as many different layout algorithms, but we're a small project.

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