Improper layout of tablature ties
1. Open attached score (produced in 2.0).
Result: The layout of ties in tablature isn't proper.
Using MuseScore 2.0 Nightly Build (1c07b89) - Mac 10.7.5.
Attachment | Size |
---|---|
Improper layout of tablature ties.mscz | 2.18 KB |
Improper layout of tablature ties.png | 32.89 KB |
Comments
Do you have a good definition for "proper" here? I can see they are short, but if you are referring to direction, this appears to be one valid way of determining it. As has been discussed before, there are lots of valid standards out there. But see #29236: Tie direction for chords on tab staves non-deterministic?
Not really the direction, just that it seems to be anchored to one side and provided little horizontal space (hence the arch). I once filed this: #23081: Tie position in tablature not centred
Here's the original - it looks ideal to me (ignoring direction).
What do you want to know?
The core problem is that tie are too short? Or there are other aspects? (centring is being addressed separately)
They might be drawn short, but perhaps they are drawn and just not expanding (they look squeezed).
Sorry, I still do not understand:
1) Ties are drawn too short with respect to note position? In other word, given the position of the notes, ties should approach them more than they do now?
2) Ties should force more space between the notes / chords they join, altering their position?
1) I'm not sure, but I think you're probably correct that the ties should approach the notes more than they do currently.
2) Handling of tablature and pitched staves is probably no different, generally speaking. In this example, things could be a little tight, but I'm not sure if it merits changing.
It just occurred to me about slurs too. The images in this topic may help?
1) Tie end points: once the PR about tie better centring will be merged, we will probably be able to tell better if and how much tie need to be expanded at sides.
2) Well, tab and standard staves are different under many respects. But probably ties should get the same treatment in either; except for one detail, easily visible in the example reproduced in #2: I see no reason to have the bottom tie wider than the other in the TAB; in the standard staff, it makes sense, as the outmost tie is outside the stems while the other are inside, but in TAB I see no reason.
So, can we agree that the core if this issue is to force more space between chords joined by ties in order to avoid over-short ties?
1) Yes, I agree. We could wait until then to judge this issue - also my response to your final question.
2) I probably wasn't specific enough, but I think I do agree.
Will this fix be extended to slurs?
"Will this fix be extended to slurs?" Ideally yes.
They look better, but now, the issue has changed - the ties are placed on the wrong stave line and not vertically centre:
Using MuseScore 2.0 Nightly Build f59e1af - Mac 10.7.5.
They look better? I have no idea why they should, not why the vertical position did change; I have not changed anything related to width or to vertical position!
Did someone else change something?
(It is becoming rather difficult to keep up with the flood of small changes here and there...)
EDIT: Tie vertical position seems to react to the width: by adding more space before the tie end note(s) (for instance vis segment leading space in the Inspector) at a certain point the vertical position 'snaps' to correct y position.
Rings a bell to anyone?
Yes, sounds like the code I wrote to make ties avoid overlapping staff lines too much. That was around a year ago. I don't remember if I made it standard staff only, but I'll bet if I didn't, I didn't correctly account for staff line distance. I'll look into this later tonight (my time).
Thanks for being on this and for the analysis. Definitely is my staff-line-avoidance code that is to blame here. It's not that I didn't account for staff line distance - I actually did. It's that the basic assumptions I made about where the ties are relative to the note heads and staff lines and which direction makes sense to move them are not valid for tab.
I can fix the biggest flaws in my assumptions, but it appears to me that ties on tab staves don't ever have the issues colliding with staff lines that ties on standard staves do, because the basic placement algorithms differ. So I'll jjust disable this code for tab. We could always enable it if we do start seeing collisions.
https://github.com/musescore/MuseScore/pull/1836
Fixed in 5048cbbf38
Marc's patch improves things, but some points are still open:
1) The main issue in the OP (ties too sorts) is still there.
2) The current code still does not take into account (as it didn't before) that height of fret marks is different than note head height, may be different from tab style to tab style and fret marks may be at different heights (ON lines or ABOVE lines).
As I have spent the good part of the day fixing this same bug, probably, I can probably build on Marc's patch.
Thanks,
M.
Oh, yes, sorry, my fix was only for that particular regression involving the staff-line-avoidance code. Sorry if I stepped on your toes again, but your previous post made it pretty clear to me it was my code at fault...
Note I do have code to enforce a minimum length for ties also, it's in layoutPitched(). There is corresponding code in Tie::slurPos() too. Probably the same approach would work for tab.
Yes, in fact, I have borrowed your code in Chord::layoutPitched() with some changes (mostly simplifications). And added some code to Tie::slurPos() to account for TAB oddities.
The ties are fine, but slurs are not centre.
Using MuseScore 2.0 Nightly Build 64cfc85 - Mac 10.7.5.
PR at: https://github.com/musescore/MuseScore/pull/1841
@chen lung: would you mind opening a new issue? Slurs and ties are related indeed, but also treated somewhat differently.
Hi
Done: #49691: Slurs not centred to fret mark in tablature
Fixed in 0e5cd00268
Automatically closed -- issue fixed for 2 weeks with no activity.