Implement "cresc." dashed line as alternative to hairpin

Project:MuseScore
Component:Code
Category:feature request
Priority:normal
Assigned:Marc Sabatella
Status:closed
Description

It's fairly common to see in a piece of music, instead of a hairpin, something like this:

cresc.   -     -     -     -     -     -     -     -

(Likewise, by the way, with dim. instead of cresc.)

This can currently be simulated in MuseScore, but it's a rather time-consuming process involving creating a custom line which ends up not looking quite right anyway:

cresc.-----------------------------

—plus, there is (at least for now) #69836: Changes to text line not reflected in linked parts.

I'd really love to see a new line style with widely spaced dashes, and cresc. and dim. lines in the Lines palette using that style with the corresponding playback effect. I'd personally be using 2.1 nightly builds as soon as it was added to the code.

Original discussion: https://musescore.org/en/node/74146

Comments

Needs playback too, I guess

That's what I meant by "with the corresponding playback effect."

oops, reading helps, sometimes ;-)

Assigned to:Anonymous» Marc Sabatella
Status:active» patch (code needs review)

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)

@Marc: Awesome!

@CombatCube's last statement: Likewise! (Some day I'm going to have to teach myself how to compile a build, but it's probably not happening any time soon.)

Status:patch (code needs review)» fixed

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

Downloading nightly now. (I really hope there is not a 2.0.3 release and we can finally get to 2.1…)

It's beautiful! And there's even a way to transform the hairpin into the text line and back again with the Inspector. Wow. Thank you, Marc!

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

works nicely.

A "crescendo line" can be converted into a "crescendo hairpin" using just the Inspector (and back again), but the reverse is not true. Probably nothing can be done for hairpins made with previous versions of MuseScore, but a slight ease-of-use improvement would be for the hairpins in the palette to already have "cresc." and "dim." secretly embedded in their text line aspect.

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.

Status:fixed» needs info

I'm almost certain that the text should be aligned differently—"Center text vertical to reference point" rather than "Align baseline of text to reference point." Is there are a reason the decision was made to use "Align baseline," or is this a mistake?

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.

I see what you mean. I'm trying to get it to line up vertically with the dynamics (the way hairpins do). Centered vertically is better for that purpose, but not great:

cresc.png

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.

Status:needs info» fixed

Or perhaps simply hard-code that the text line form of a hairpin is offset .5sp? Keeping the text base-aligned, as Gould recommends.

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

I would tend to doubt anybody would be changing it from FreeSerif, but I tried a few different fonts and the alignment is almost the same anyway.

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.

Good point. It seems the alignment problem is rather worse with MuseJazz—
cresc2.png
but since this seems to be such a complicated issue, realistically I'm prepared to leave well enough alone and say it doesn't really matter if it's aligned with dynamics or not. ;-)

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 :-)

Changing the layout of the hairpin to align to its baseline could cause problems as soon as somebody went to adjust the width of its jaws (I don't know what else to call it).

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

I'm perplexed to see this added to the hypothetical 2.0.3 branch—the new element would not be compatible with existing 2.0 releases, would it?

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.

True, hairpins created as textlines simply display an ordinary hairpins. But upon saving the score with 2.0–2.0.2, it no longer is interpreted correctly when reopened with a 2.1 nightly. (Anyway, I hope this conversation is hypothetical and the next version is 2.1.)

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.

So, this would not be fully compatible if included in a 2.0.3 release. Loss of information counts as a major bug, remember?

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

But I'm fairly certain that the whole point of delaying 2.1 and putting out another 2.0 release would be to be 100% compatible with existing 2.0 releases, backwards and forwards with no information lost.

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.

So what are the changes that are in the 2.1 branch (with the new file version number) but not the 2.0.3 branch, and why? You might also say there's a very tiny likelihood that anyone would be silly enough to use a feature that is new to a 2.1 release, go back to 2.0.x and load that file and save it again (and in that case I'd agree with you—the software version number is different enough to act as a warning sign against that), but it's true that a file saved with a 2.1 nightly build can indeed be opened in 2.0.2, with some very slight potential losses. However, there is a warning dialog when you try to do that. There would be no such warning dialog when opening a score saved with 2.0.3 in 2.0, 2.0.1, or 2.0.2.

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?

Status:fixed» closed

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

Syndicate content