Non-5-line drumset stave lines incorrectly positioned

• Dec 5, 2012 - 11:43
Type
Functional
Severity
S4 - Minor
Status
closed
Regression
No
Workaround
No
Project

1. Open attached score (produced in 1.2).

Result: The lines are incorrectly positioned, compared to MuseScore 1.2 and a published score.

Discussion: LilyPond seems to have the same result as MuseScore 2.0.

Using MuseScore 2.0 Nightly Build (8555492) - Mac 10.7.5.


Comments

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.

I agree about removing '3-line drumset' from 'Instruments' (discussed here ), but yes, I would like the ability to adjust lines in 'Stave Properties...' (or perhaps wherever) and have them correctly presented - hence, leaving this issue open.

I've just realised that this also applies to '2-line drumset' - the time signature isn't presented correctly either. I wonder if other instruments could be similarly affected if stave lines are changed.

Regarding MusicXML, I'm curious - what will happen if you import/export a score with less than 5 stave lines to another program, or perhaps even MuseScore (in the future?)? This maybe of interest: #16302: [MusicXML] Instruments with less than five stave lines appear with five stave lines

Using MuseScore 2.0 Nightly Build (8555492) - Mac 10.7.5.

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.

I think the published score (by International Music Publications and engraved by Barnes Music Engraving) was produced in a software called Amadeus (according to an interview ).

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.

1. Open attached score (produced in 1.3).

Desired result:

Drumsets with less than five lines - Desired result.png

Actual result:

1.3

Drumsets with less than five lines - Actual result (1.3).png

2.0

Drumsets with less than five lines - Actual result (2.0).png

-----
I believe for drumsets with less than five lines:

The barline should be the same length as a standard pitched or 5-line drumset stave.

The line distance should be based on the 5-line drumset - lines are omitted and the positions of the remaining ones retained (1.3 appears to do this).

1 line: The middle.
2 lines: The inward lines (not middle or outer).
3 lines: Outer and middle lines.

Using MuseScore 2.0 Nightly Build (aadeb95) - Mac 10.7.5.

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.

Status (old) fixed active

It's a bit better, but there are still problems:

Example 2

Expected result:
Drumsets with less than five lines - 2 (Expected result).png

Actual result:
Drumsets with less than five lines - 2 (Actual result).png

Instrument names for one-line entries are off-centre.
The brackets don't encompass 1 line staves fully (should be the length of a standard stave).
The stems are too long.
Rests are incorrectly positioned in Percussion 4 (should be centre).
The accents in Percussion 4 are too far from the noteheads (not sure if it's due to later scaling adjustments).

Example 3
Drumsets with less than five lines - 3.png

Unnecessary ledger line is introduced for note.
Ledger line rest isn't positioned correctly (should be centre - on the non-visible middle line).
The brackets don't 2 line staves fully (should be the length of a standard stave).

-----
Both scores were produced in 1.3.

Using MuseScore 2.0 Nightly Build (1c07b89) - Mac 10.7.5.

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.

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.

Status (old) active patch (code needs review)

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:

Drumsets with less than five lines - 2.png

Status (old) closed active
Status closed active
Reported version 2.1

My apologies for re-opening this and so late on, as I didn't check Marc's PR at the time, but looking at such scores now suggests that there may have been a regression, because it seems to look similar to the way it was when I filed this issue (rather than the last image uploaded by Marc).

The attached mscz was produced in 2.1.

Using MuseScore 2.1 and 2.2 Nightly Build ad25622 - Mac 10.11.6. 3.0 Nightly Build 9d9cd89 is a different result (possibly some things are broken).

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.

Reported version 2.1  
Regression No
Workaround No

What are the chances of this making it into series 3?

It's one of a few key things for me that prevents such scores of mine from looking decent.

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.

Status active closed

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:

three-line.png