Layout issues on import of 1.3 score with accidentals & tuplets

Did you create a patch to fix this? I'm guessing not, so I'm changing the settings.

In my tests, I find music top margin does not affect distance above the first system if there is a text box (eg, the title frame on the first page) above, but it does affect pages in which there is no text box above the first system. Not sure if that's intentional or not. You can increase distance below text boxes individually, so it might be a deliberate change to have the music margin not affect this any more.

If you are seeing something other than this, please post the score you are having problems with, and the precise steps to reproduce the problem with a current nightly build (there is no beta 2 yet, and the beta 1 is several months old now).

OK. I still don't know know if that was an intentional change or not.

You also mention a 1.3 score that does not load properly - can you post that? Or do you just mean, the change in interpretation of top margin is affecting your 1.3 scores?

And meanwhile, please don't "assign" yourself unless you plan to fix it :-)

Sorry, I missed when this was posted. I see a number of issues with the import here, some of which are bugs but some are just a matter of things having changed for the better but your workarounds for the previous bugs are now causing problems.

- The "fake" tempo marking with the tuplets is not likely to work; you're depending too much on things likely to change from release to release in terms of layout. Even within one release, this won't likely stand up to changes in score scaling or other layout changes. Better to use an image for that.

- The string number layout has changed and is more sophisticated in 2.0, but that does mean you'll have to readjust string numbers that were adjusted manually. Not sure what if anything we can reasonably do to automate this.

Whatever is happening with the sixteenths overlapping the tuplets in bars 3-4 definitely looks like a bug, or two:

- Beat 2, voice 1 should start with E D# but instead starts B D. That's really weird and I can't explain it at all.

- The duplicate "#" signs on the A# on beat 3 should not be happening. This goes away if you re-enter the notes or edit the pitch on both voices using up & down arrows then return them to A#

- The original score has an erroneous A natural as the very last note of measure 3, voice 4. A but in MsueScore 1.3 prevented that from appearing, but it appears correctly now in 2.0. This change is for the better; you just need to fix the score.

- The sixteenths overlapping the tuplets look better once these issues are fixed, but it's still overlapping. Something is going very wrong with the layout calculations but I can't tell what.

Anything unusual about how the score was created that could explain any of this?

Beta 1 is more than 4 months old, hundreds of bugs have been fixed meanwhile and Beta 2 is available since a good week, so you may what to got that a try

As I explained before, the behavior of the "music top margin" has changed; it now literally only affects the distance betwene the top margin and the first system instead of doubling as a contro over the distance between a vertical frame and the first system of a page. I suspect that change was deliberate; it really seems more like a bug in 1.3 that is fixed now.

As for the 2.0 builds in general, of course there are bugs. But we can't fix them if you don't report them, so please, do continue to try and report all bugs you find, in separate bug reports in the issue tracker - or if you are not sure if it's a bug, in the Technology Preview forum.

FWIW, my impression having been using 2.0 builds more or exclusively for the past year or so is that somewhere in the months between Beta 1 and Beta 2, we've reached a point where 2.0 builds are actually *less* buggy than 1.3 overall.

Yes, I opened the score with 1.3 to see the differences. As I explained, many of the differences are not bugs at all but just normal differences to be expected due to the specific tricks that were played in the original score, or bugs in 1.3 that are now fixed. And actually, as I look further, I am finding that only one of these differences seems to be due to a bug in 2.0, and that is the overlapping notes at the beginning of bar 4.

The problem with the multiple #'s signs on the A in bar 3 is that the score uses an explicit "user" accidental for one fo them, rather than the normal kind you create by entering an A then presisng the up arrow. So MuseScore 2.0 is doing the correct thing here; a bug in 1.3 that is now fixed in 2.0 prevented you from seeing this error in the score.

The problem I thought I was seeing with the notes changing from E D# to B D is my error; it is B D in both.

The overlapping notes is seemingly caused by there simply being too much going on to fit on one line, but the question is, why didn't MuseScore move bar 4 to the next line? Note that the reason it could fit in 1.3 but not in 2. has to do with those 1.3 bugs I mentioned - the fact that it it erroneously did not show some of the accidentals it should have. But even once you correct the errors in the score - so you get only on # on the first A and no natural on the last in bar 3 - it still doesn't fit, whereas it did in 1.3. The layout algorithm has changed in a lot of ways, so it's to be expected that sometimes something that used to fit won't any more (and sometimes, but not as often, vice versa). But still, this should be handled correctly, by moving the bar that doesn't fit to the next line, and I don't know whay that isn't happening here. I've never seen this in any other socres, which is why again I wonder if there is something unusual about how this one was created. like way it perhaps imported from MusicXML, or something like that.

Loading the file into a current 2.0 build and correcting the errors in the original (the inapprorpiate user accidental and the "unison" A/A#), I no longer see any issues. Not that I am aware of anything specifically having been fixed. But seeing as the layout glitch in the last measure seemed to have been unique to this score, and is no longer reproducible, I am marking this "fixed". It's certainly possible some *other* score will show similar issues, but if so, we'd need to see that score.

Automatically closed -- issue fixed for 2 weeks with no activity.