Implement "cresc." dashed line as alternative to hairpin

Needs playback too, I guess

oops, reading helps, sometimes ;-)

Here is a cheap but effective implementation. Maybe it's not the best way to do it, but the other methods I considered would have been quite a bit messier.

https://github.com/musescore/MuseScore/pull/2181

Cool feature! Just a couple of concerns:
- Is there a new Text Style for this element? (or does it just use Text Line's style?)
- Can the line be set to invisible? (I'd prefer to use this instead of staff texts for all cresc.'s and dim.'s, even where the line is not notated)
- Can the text be modified? (For example, some editions prefer "decresc." instead of "dim.")

I can't wait to try it out in the nightly!

- So far, no new text style, although of course one could be added. I use textline style but the two palette items I added have text with embedded italic tags, so they show as italic.

- Yes, lines can set be set invisible, see Inspector "Line visible". This keeps the text but makes the line invisible. This is also used for the new 2.0.2 pedal on/off symbols

- Yes, text can be modified as for all textlines - right click, Line Properties (that's why I made sure to make this option available if the useTextLine flag is set; see the PR)

Fixed in branch master, commit 04604f5c74

fix #74171: cresc. and dim. lines

Fixed in branch master, commit 1100b9bc43

Merge pull request #2181 from MarcSabatella/74171-cresc

fix #74171: cresc. and dim. lines

You're welcome! Glad there turned out to be a simple solution.

works nicely.

True, not a bad idea. It would actually not be impossible to do this when importing older scores either. Feel free to file a feature request for it.

Gould uses baseline in "Behind Bars", so we do too. No doubt others do it differently. You are welcome to change this for your own scores, but unfortunately, vertical centering doesn't work so well with text that is all lower case - it's based on the maximum height of the text, not the actual height. So you'd also have to add a vertical offset.

You could always change the dynamics text style and/or the default offset in the hairpin general style. Probably not a way currently to get everything to line up perfect by default - if you get the textlines version to align, the hairpin version proabbyl won't. But worth some experimenting. I guess we could stand to add a couple of new general style settings for these new lines - default vertical position, default line style.

I think the specific amount, though, will depend on the font.

Changing font would be pretty common really - jazz scores will use MuseJazz by default - but change *size* is perhaps more to the point. Fudging numbers based on the characteristics of the default font is not a good solution.

In hindsight, I see what is going on and how it should have been solved.

The default dynamic text style vertical alignment set to baseline, so does the default hairpin text style. So for a given position, they should align perfectly. However, the dynamic position is set to -8.0sp in the text style, while the hairpin position is set to 7.5sp in the general style. This was done specifically in a effort to make them align, because while the dynamic aligns to the baseline, the hairpin aligns to the point (ie, half the height of the hairpin). If the hairpin were aligned to its baselines, then we could have set its default position to 8.0sp default position, and then it would still align perfectly when converted to a text line.

So if we wanted to fix this, one way would be to change the layout of the hairpin to align to its baseline, change the general style default to 8.0sp, and write some code to adjust everything for older files. Or we could add a new style parameter for the height of text lines.

Or I could just add 0.5sp to the position for the textline and call it good :-)

I submitted a PR for now that includes the 0.5sp adjustment: https://github.com/musescore/MuseScore/pull/2199

EDIT: posts crossed, and you're right :-). There's no ideal solution here, just a choice of different hacks.

Fixed in branch 2.0.3, commit 3dedc1f4cf

fix #74171: cresc. and dim. lines

Someone correct me if I'm wrong, but the way I understand it is older versions of MuseScore will simply ignore new features, so they can still open the file (nothing will break) but the new feature won't be there. I imagine that it is changes to existing features that cause compatibility problems, not completely new features.

This PR sets a new property for hairpins xml.tag("useTextLine", true); which replaces the hairpin with a text line. Perhaps 2.0.0 users would see an ordinary hairpin instead?

In some cases new features will be ignored, in other cases they might cause the file to not be unopenable, or to cause crashes corruption or other problems. We try to manage the internal version number to make sure anything that would cause real problems will trigger a message saying your version of MuseScore is too old. We don't want to have to bump the internal version number for 2.0.3 - we want 2.0.2 to be open to open 2.0.3 scores. So we can only allow new features that won't cause problems.

Apparently, so far, testing seems to suggest it won't be a huge problem; hairpins created as textlines should simply display an ordinary hairpin. unless the recent change to retroactively add text causes worse problems. More testing would be good.

Well, it is interpreted "correctly" according to the version you saved it with. A score saved with 2.0.2 will contain only 2.0.2 features.

As a general guideline, sure, but loss of information that just isn't there in 2.0.2 is totally different.

Not necessarily. Maybe the pros of having the feature outweigh the veyr tiny likelihood that someone would be silly enough to use a feature that is new to 2.0.3 feature that doesn't exist in 2.0.2 and then go back to 2.0.2 and load that file and save it again. Really doesn't matter to me one way or another if this feature goes in, but I think you're worrying over nothing. it's better to have the feature than not, and if someone does something silly that eliminates those lines, they are no worse off than if the feature was never added.

Many changes in or planned for 2.1 are just flat out incompatible - score would simply not be able to load, would be missing crucial information, would be corrupt, would be likely to crash, etc. There would be no way to include the feature without a version number change. Or, maybe the feature is just too big, would require too much testing, to consider putting in a 2.0.3, which realistically would barely impact the 2.1 schedule at all.

This really is a very special case, and like I said I have no special attachment to having it in 2.0.3, but I really do not understand your concern. As I said, if you use the feature in 2.0.3 then for some silly reason to decide load that same score into 2.0.2 and edit further than save it, you are in *exactly* - and I mean *exactly* - the same position as if you had never used 2.0.3 at all. You still have the hairpins in *exactly* the same form they would be had you added them using 2.0.2 instead of 2.0.3. It would be *exactly* as if the feature were not added for 2.0.3 in the first place and you had followed the same steps, adding a hairpin instead of a cresc line because that was your only choice. Only better, because at least you wouldn't have been tempted to add it as staff text or ordinary dynamics. Once you realize your silly mistake and load the score back into 2.0.3, it would take *seconds* to change those hairpins back into text lines if you desired.

Why deprive people of an extremely useful feature just because of a tiny likelihood of something that is essentially a non-problem anyhow?

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