3.0: Manual positioning of many elements not retained
This score I have created with MuseScore 2.3.2 on Windows 10:
When I open it in MS3 and don't reset the positioning, text and line elements are positioned differently:
If I choose to reset positioning, things are not better:
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 hmm...well this is too bad. … by ericfontainejazz
Here's the score. Uses the Old Standard TT font.
In reply to Here's the score. Uses the… 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 Assumption: manual… 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 Because it's a major version… by Marc Sabatella
In the company I work for, this would never be accepted. A single user reporting that a Song they created plays differently on a newer machine, for whatever reason, would cause a bug to be filed and we, the developers, would work hours fo fix it.
In reply to In the company I work for,… 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 Because it's a major version… by Marc Sabatella
I can just quote all this article:
https://www.peppercarrot.com/en/article396/new-inkscape-0-92-breaks-you…
In reply to I can just quote all this… by faben70
The end of that article reveals how they were able to fix the import bug. Maybe you can help fix this, too!
In reply to The end of that article… 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 Yes, it reveals that "thanks… 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.