Lyrics: Better dash control

[mgavioli]

This patch gives better control on lyrics dash management and it is intended to supersede #2213 which did not suit the taste of several forum users.

References:

• for a discussion of this patch, see https://musescore.org/en/node/81796
• for a discussion about the previous patch, see https://musescore.org/en/node/76021 .

Adds 3 new score style parameters:

• lyricsDashMinLength to control the minimum dash length (default: 0.4sp)
• lyricsDashMaxLength to control the maximum dash length (default: 0.8sp)
• lyricsDashForce: if set to true, a dash is always generated between two syllables of a word and, if there is not enough space for the min dash length, more space is added between the syllables to accommodate it; if set to false, no extra space is added and the two syllables are joined together (default: true)

The effect of the last parameter is exemplified by the following screen-shots:

Current situation (before this patch); if there is no room for the min dash length, the dash is skipped and some blank is left between syllables (-pre dan-):

Patch with lyricsDashForce = true; syllable chords are further spaced and a min-length dash is inserted (-pre-dan-), at the cost of looser fitting and of altering the proper note spacing:

Patch with lyricsDashForce = false: the second syllable is moved (slightly) to the left to reclaim the blank (-predan-), keeping the best possible fitting and note spacing:

User controls for the three parameters have been added to "Style | General" dialogue box, "Sizes" tab.

[Jojo-Schmitz]

I like the look (and the alternative) better. But wouldn't it be simpler (and more intuitive) to have lyricsDashMinLength decide whether or not a dash is shown? Set to 0 and none will be shown, set to something >0 and it it will be forced? Not quite sure whether lyricsDashMaxLength is needed and for what purpose.

[mgavioli]

@Jojo-Schmitz : maybe simpler, but to my (twisted?) mind not intuitive at all; a dash 0.01sp long would look absurd. The point is not to hide the dash unconditionally, but only if it "does not fit"; and for this a threshold (a minimum length) is needed below which it is possible to say that "it does not fit".

The max length is exactly that: it defines the extension of the 'full' dash, when there is no space constrain and the dash can be drawn in full. The length appears to vary in editions from different publishers and different users may like different lengths, as the space between bar line and note, between note and bar line, accidental and note and so no, are configurable.

[Jojo-Schmitz]

a dash of 0.01sp would (almost but close enough) look like it currently does, so why now?
Good point about max length, I'm not against it but didn't see a real Need.

[shoogle]

These are both greatly improved over the current default, good job!

I personally find it much easier to read with a dash (i.e. lyricsDashForce = true)

Patch with lyricsDashForce = true; syllable chords are further spaced and a min-length dash is inserted (-pre-dan-), at the cost of looser fitting and of altering the proper note spacing.

Why not keep the proper note spacing and simply move the "dan" syllable right a bit to make room for the dash? The "dan" would no longer fall directly under the minim (half-note) but it would still be perfectly readable. I know that this is not always an option (i.e. it wouldn't work if there was a sequence of closely-spaced notes) but it could work very well when only two or three notes are close together.

[MarcSabatella]

@shoogle : to me that might be a valid personal choice in some cases, but I don't think it is standard behavior and should not be done by default, unless you can find an authoritative reference and published examples that recommend this.

[mgavioli]

@Jojo-Schmitz : I think this reply on the forum thread addresses your concern about min dash length: https://musescore.org/en/node/81796#comment-361431

[shoogle]

@MarcSabatella : fair enough. I don't have a reference (haven't time to look currently) so perhaps it shouldn't be the default, but it strikes me it could be sensible and efficient behaviour if the user were to reduce the stretch below 100% on such a bar.

[MarcSabatella]

I reduce stretch all the time for various different reasons, none of which should result in non-standard lyrics placement. Again, if you personally have a special case reason to want to adjust certain syllables, you are welcome to do so manually, but MuseScore's default behaviors should give standard, not non-standard, layout.

[shoogle]

I didn't realise that "reduce stretch" tries to preserve standards compliance. I had assumed that 100% stretch would be "as compact as possible without breaking standards compliance". Since that's not the case and standards compliance is preserved after all, I guess it explains why things break so quickly as you reduce stretch and keep reducing it.
I often use "reduce stretch" and have thought for a long time that it is looking to save space in the wrong places. I am regularly disappointed with how little the stretch can be reduced before the layout corrupts. Perhaps I will have a go at implementing an optional "Relaxed Standards Compliance Mode" in the preferences where the normal compliance rules are usually enforced, but may be bent, or even broken slightly, if enables a more compact layout or otherwise improves the appearance of the score.

[MarcSabatella]

100% stretch doesn't mean as compact as possible; it means apply the default spacing according to your current settings - in particular, Style / General / Spacing. It's really just an measure-specific override to that score-wide setting.

Reducing stretch is basically the same as reducing that setting, but there are lots of other relevant settings that influence how comapct your music can be laid out. See in particular "Minimum note distance" but also other settings in there. If you want highly comrpess music, you can generally get it already just by changing style settings, no need for stretch adjustments.

[MarcSabatella]

Also, FWIW, it's not really about strictly enforcing compliance to some sort of standard. It's just that the spacing algorithms are kind of "naive" and really doesn't have any concept of how to deviate from the normal "regular" note spacing except in the specific cases where support for some particular exception happens to be built in. There might be plenty of places where standard conventions allow for irregular spacing but we don't currently handle those cases. From what I understand @wschweer is working on further improvements to the basic note spacing algorithms.

[shoogle]

Very interesting, thanks for elaborating. I reckon I know MuseScore pretty well by most people's standards, but this just goes to show how much there is still to learn!

[mgavioli]

UI added. I believe the PR to be ready for merging and wider testing, including fine tuning default values of min / max dash lengths.

[mgavioli]

@lasconic @wschweer : Possibly a good candidate for 2.0.3 merging too? The only change which can be 'seen from outside' (from a non-2.0.3 MuseScore version) are the 3 additional score style parameters and they would be ignored by 2.0.2, wouldn't they?

Incidentally, I didn't find an easy way to check if a specific PR has been merged to 2.0.3 or not, beyond manually browsing the 2.0.3 list of commits; apparently, there is no indication of this in the PR page itself. Did I overlook something?

[Jojo-Schmitz]

It is far easier to track if there is a corresponding issue in the issue tracker and the commit message used the proper format

[lasconic]

Hi,

the 3 additional score style parameters
Unfortunately an unknown style parameter crashes MuseScore 2.0.x...
It has been fixed for 2.0.2 only 8c6a953

To know if a commit has been merged in 2.0.3

git checkout 2.0.3
git log --grep "commit message"

[Jojo-Schmitz]

So we can't merge this into 2.0.3 to maintain compatibility with 2.0 and 2.0.2, right?
Unless we bump up the file format version and that way inform users that they'd need to upgrade...

[mgavioli]

Ok, I understand, tough luck for the 3 parameters...

About commit checking, I hoped for a way to see this through github itself, to avoid void checking 2.0.3 in and then out, triggering a big recompile each time. But never mind, I managed to do what I was after. Thanks anyway!