Distance between stem and note head in tablature
1. Open attached score (produced in 1.2).
2. Right-click stave.
3. 'Stave Properties…'.
4. Change 'Type:' to 'Tab'.
5. 'OK'.
Result: The stem maybe too close to the note head compared to the original published score.
Using MuseScore 2.0 Nightly Build (49801cc) - Mac 10.7.5.
| Attachment | Size |
|---|---|
| Stem too close to head.mscz | 0 bytes |
| Distance between stem and note head in tablature (MuseScore).pdf | 9.5 KB |
| Distance between stem and note head in tablature (Original).png | 48.76 KB |
Comments
I post here (instead of the Issue Tracker) because I'm not sure if this report is valid, or if there's enough information.
I don't know why the mscz is empty, but here is another one.
Here is a clearer 'Original' image.
Please see my replies in this and in this post.
Thanks,
M.
I know it may differ between books because there seems to be no standard, but I'm not sure I'm happy with what is currently in MuseScore - it seems too close and inconsistent (see this ).
Here's an example from a different publisher - Wise Publications.
The stem seems to penetrate perhaps a quarter into the space. Could we maybe agree on that, or something similar?
In reply to I know it may differ between by chen lung
I see what you mean and the example you give has its elegance.
However, there is a technical complication when there are several notes in a chord (it is a bit difficult to explain by words; I'll try).
Currently, the code draws the stem as a single continuous line from the 'first' 'note' (where 'first' is the top note for down stems and the bottom note for up stems) up to its end. Then each 'note' is drawn with a solid background to erase the part of stem (and of staff line) colliding with it. If the note area is enlarged, the note drawn as second risks to erase part of the note drawn previously (if there are no empty strings in between).
Of course, it can be solved, but there is no 'free lunch'. I see three possibilities:
A) A previous drawing pass is added to erase the stem portion under each note; the erased area can be significantly larger than the note area without risk, as no note is drawn yet.
B) The stem is drawn in sections, only where not 'obscured' by notes.
These two possibilities may make the drawing code more complex (and slower!) by a non-trivial amount. There is a third possibility (of which we already spoke for other reasons):
C) The stem is drawn only from the 'last' note (where 'last' is the bottom note for down stems and the top note for up stems) with a distance larger enough between note and stem.
In this case, however, any 'hole' between strings (unplucked string between plucked ones) will have no stem indication. If this is acceptable, this solution would be no more complex than the currently implemented one and could accommodate any amount of 'air' between notes and stems.
Comments? (By chen lung AND by anyone else interested)
M.
In reply to I see what you mean and the by Miwarre
Thanks for the explanation!
Unless there's objection, maybe you could just do what you think is best and we'll go from there? If it doesn't work, we could try the other ways.
It maybe relevant to say that in looking at the image here , the stems in-between notes in a chord also seem a little too close to the number? Also, some stave lines seem different.
In reply to Thanks for the by chen lung
Stems in-between notes keep the same distance from notes as stem parts below (or above) the whole chord (i.e. very little). Staff lines are drawn like all other staves; as lines are very thin (less than 1 pixel) at that zoom factor, rasterisation may play tricks.
"Unless there's objection, maybe you could just do what you think is best and we'll go from there? If it doesn't work, we could try the other ways."
This makes sense to me; I'll finish the in-progress points and, if no voice against is raised; I'll go for option C) above.
Thanks,
M.
In reply to Stems in-between notes keep by Miwarre
If i'm not wrong, lilypond does C) by default. I can't find an option to make it draw the full stem between frets.
Sibelius default to C but can also draw stem between frets optionnaly. Only when the stems are drawn in the staff.
In reply to If i'm not wrong, lilypond by [DELETED] 5
Regarding the stems between frets, see this .
In reply to If i'm not wrong, lilypond by [DELETED] 5
Ideally, it would be a configurable choice, but we cannot go on indefinitely adding parameters and choices (the TAB config. dlg box is already quite complex). I believe that a choice has to be made here; then, more parameters can be added in future releases if there are requests.
If both Lilpond and Sibelius both default to C (with or without configurability), it may make sense to go for C) in MuseScore too. Which means in practice:
1) No stem portions between fret marks
2) More 'air' between the stem end and the first mark (I would estimate ca. 0.25sp for an initial implementation).
Agreed?
M.
In reply to Ideally, it would be a by Miwarre
I think C would be okay?
We can try it anyway and see how it goes :).