Non-5-line drumset stave lines incorrectly positioned

I'm proposing to dump the 3 line drumkit in the new version of Instruments.xml

The reason for this is partly to do with MusicXML 3.0 compatibility and partly because 5 line notation for drumkits now appears to be the norm.

The user will be, of course, perfectly at liberty to define a custom staff of this kind should they so wish, but it will no longer appear in the Create Instruments dialogue.

SO I'll leave it up to you Chen whether to close this, or leave it open until the new Instruments.xml has been completed and sent as a pull request.

It seems to me that the problem is a matter of line spacing: have you tried to set the 3-line staff line spacing to 2sp? It should achieve pretty the same result appearing in the published score (published by whom, BTW?)

If this is true, the default can be changed rather easily, I think.

This may or may not help with other non-5 line staves though, as the given examples of 3-line staves are peculiar in their line spacing.

M.

Have you tried to see if you can achieve the intended result by playing with staff line spacing? (In staff type properties).

This might be a guide for the developers to set more appropriate default values for the various staff types.

M.

Most of the problem with staff with number of lines !=5 comes from the fact that we used to use the central line of 5line staff for one staff, and add the 1sr and the fifth for 3 lines staff. Now, we used the top one for single line and it's then needed to move everything up, full measure rests, time signature etc... Also I'm not sure if the spacing between staves will be good because of this. Maybe it's not too late to revert this change? Not sure how it will impact tablature though?

Well, in fact, for 1-line staves, the second line is used, not the top one (see StaffLines::y1() function in element.cpp).

In addition, I keep finding code points where default values of 5 lines and 1sp line spacing are assumed; when I modify one of them (for instance when working on TABs), I usually convert it to use actual staff parameters, but the recurrent use of literal values rather then symbolic constants, makes difficult to understand all the cases (for instance, it is not always easy to understand than a value of 4 is used as the default height (in spaces) of 5-line single-spaced staff).

Which change do you propose to revert? No change has been introduced yet because of this issue.

Anyway, changes in how lines are counted or spaced in pitched staves should not affect tablatures, as they are (well, should be!) ready to accept any number of lines and any line spacing.

M.

Looking at the score in the original, and indeed *any* 1.3 score containing a 1-line drum score, it does look pretty bad in 1.3. Not sure what the deal is; I don't know this code at all. But is it possible to get a 1-line drum staff created using all defaults in 1.3 to import into 2.0 more or less the same way a new-from-scratch 1-line drum staff looks in 2.0? Same with 2- or 3-line I guess.

I just realized, I'm talking about barline height, because I got here from a link in another bug having to do with 1-line staves. Didn't realize this was primarily talking about line distance. I'd agree with the idea that default line distance for instruments who pre-defined template uses 2-4 lines should be adjusted if possible.

I have a fix for the bad bar line length. As far as I can tell, it's not just drum staves affected - any staff with a non-standard number of lines gets the wrong barline length. So that much is safe I think.

I see exactly where I *could* also force 3-line staves to be double-spaced, at least for percussion staves. But I have no insight into how this would actually affect 1.3 scores.

EDIT: posts crossed. The example helps - by verifying that there would be more to getting this to work than merely matching line spacing. 3-line drums sets imported from 1.3 are going to look wrong either way.

See https://github.com/musescore/MuseScore/pull/1207. I have the spacing fix in but commented out, since it won't actually work anyhow.

Fixed in e77edb9227

Well, as I said, it isn't really likely things would actually work well. Non-standard staves are going to require special coding. All I really expect we support out of the box are 1 and 5 lines staves, and we do, except maybe the name centering and bracket. Regarding other non-standard staff configurations, those are really a bunch of separate issues you are describing, but I guess just keeping them here for future reference is probably as good as anything.

This is at least partly fixed with #58796: Bracket and instrument name misaligned to one-line staff.

Partially, sure, with respect to some fine alignment details. There are still fundamental differences in how the lines are assigned that make drum sets designed for 1.3 not work correctly in 2.0 for staves of fewer than 5 lines.

Also, there is a curiousity with 2-line staves in particular that just came up here:

https://musescore.org/en/node/70346#comment-321781

Apparently, there is special casing of 2-line staves that was developed to increase compatibility with 1.3, but it does not do the right thing for pitched staves. It makes the top line be treated as 2 instead 0, in a kind of roundabout way. So a drum defined to display on line 0 with display floating above the staff, but with no ledger line, because the specific way this is done does not work properly. And a note on the bottom staff line *will* display with an obviously unnecesswry ledger line. That is what is shown in #15.

I'd like to fix this, but can't say that I totally understand what the expected results should be. I know I care much less about emulating 1.3 than about doing the right thing for new scores.

My naive first impression is that I shoudl make it so the rests are centered but make staff line 0 always be the top line.

I have been working on the problems brought up in the this thread and actually have most of it under control now. See https://github.com/musescore/MuseScore/pull/2159. It addresses the following:

- vertical position of rests
- stem length
- bad ledger lines
- bad position of notes on 2-line staves

The bracket & barline issues with 1-line staves were fixed a while ago, as mentioned.

The main remaining issue is articulation position on double-spaced staves, which I hope to fix as well, but I might end up making a separate issue for that.

Part of my change is renumbering the staff lines (again, sorry). I keep 0 as the top line like 2.0 - 2.0.2, but I number the staves of a 3-line staff 0 2 4 rather than 0 4 8. The advantage is it makes the pitch/line information independent of the spacing information, so you can change spacing and without messing things up; this also made it possible to get key signatures and other elements to display better on double spaced staves. I can fix up older scores (both 1.3 and 2.0 - 2.0.2), but not sure about .drm files.

I worked on articulation placement and updated the PR. There were a ton of special cases for articulations, but I was pretty thorough. No doubt some corner cases might remain where defaults could be better, but at least things aren't obviously broken.

Here is the current status using the example above:

The aforementioned PR was merged so it should be as in the above image for 2.1.

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

Indeed, the changes were merged for master, but 2.1 was not built from master, so the changes are not there. And master has changed since then to the point where my changes are no longer recognizable to me anyhow and it only half works. So unfortunately, looks like this will need to be looked at again.

2.1 back than was master, which is now 3.0.

I see quite a few different things discussed here, most of which work as expected, and even those that don’t surely work differently than five years ago. If you are having a problem in a current version, best to open a new issue devoted to that specific problem, with a single clear example demonstrating the problem.

FWIW, the example posted in https://musescore.org/en/node/19197#comment-816830 appears to work as expected for me in 3.3.4 (once I change the incorrect old-style line number for the single-line staff)). So I'm closing this issue. Again, if there is a specific problem affecting 3.3.4, please open a new issue dedicated to that issue alone.

Here is how the example looks in 3.3.4 with that one fix to the score: