Text of cresc. and dim. lines does not reflect type changes
Repro steps:
1. Add a crescendo hairpin to some notes
2. Select the hairpin
3. In the Inspector, select the "Text line" checkbox. The hairpin changes to "cresc. ____"
4. In the Inspector change type from Crescendo to Diminuendo. The text remains "cresc. ____"
I would expect the text change to "dim. ____"
Comments
Confirmed, also adding a cresc.___ line (rather than cresc. hairpin) directly (via the Lines palette) and changing to Diminuendo doesn't change the text.
MuseScore 2.2.1, Windows 7
Even worse in master, any attempt to change a hairpin via inspector leads to a crash (so I can't even check whether it otherwise has the same issue as 2.2.1) with message:
Fatal: HairpinSegment unknown <>(90), data <1> (...\MuseScore\libmscore\element.cpp:1057, virtual bool Ms::Element::setProperty(Ms::Pid, const QVariant&)
In reply to Even worse in master, any… by Jojo-Schmitz
I cannot confirm this on master
(OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (32-bit): 3.0.0, revision: 6969419)
There is no "Text line" checkbox in master. But the type includes "Crescendo Hairpin, Decrescendo Hairpin, Crescendo Line, Decrescendo Line". Toggling Cresc/Decresc Line also changes the line text.
Did you select the hairpin and a second object?
But: Shouldn't the types be named "Diminuendo Hairpin", "Diminuendo Line" to match the line text "dim. ____"?
Strange it crashes here, Windows 7 and self-build in DEBUG mode. You build is outdated though, we're at 82e81eb meanwhile.
And to match the name in the palette, yes, those texts should probably get changed
In reply to Strange it crashes here,… by Jojo-Schmitz
I can confirm your issue on OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (32-bit): 3.0.0, revision: 82e81eb
You mean the crash? Should be reported as a separate issue I guess, but seems to be due to a fairly recent change
Yes, the crash
OK, entered as #271095: Changing hairpin type in inspector leads to crash
master has yet another problem: the button in inspector doesn't change between the different types, regardless what type gets selected in score
I thought I remembered this being a problem in 2.1. I just tested this and it's not a regression it's been present at least since 2.1 if not before. The actual issue is that the text will never change if it is a text line rather than a < or > line.
Most probably 2.0.3 too, so ever since these got implemented (see #74171: Implement "cresc." dashed line as alternative to hairpin
FWIW, it was never really intended that the dropdown in question would apply to these lines - it was really meant to be relevant only for hairpins. Not a bad idea to have it change the text for the lines, though, but we'd have to consider the possibility that the user is wanting text other than the defaults. Personally I'd favor just disabling that control if the text line box is checked, just as we do the other controls that are not relevant for text lines.
In reply to FWIW, it was never really… by Marc Sabatella
Disabling the combobox in question will not work for master, because there is no checkbox "Text line" anymore. Just four items in the combobox "Dim/Cresc Hairpin/Text line".
I see no contradiction in default text and custom text. You can still add a custom text. Only when you change the type it goes back to the default text.
The thing is, there really is no "default text". There is just text that happens to present in the two palette items, but it's not really special to the code. So the dim line really doesn't know the other one is called cresc any more than a staccato dot knows there is also a tenuto line in the palette. Also, say you customized the text from "cresc." to "crescendo", then switched to dim, then back - what would you expect?
Not saying it couldn't be done, but to me it's more a feature request than a bug.
I do not get the line from the palette, as you see in the repo steps in my first post. I insert a hair pin and change it to a text line with this checkbox. Hence I presume, there must be a default text somewhere.
There is indeed, see https://github.com/musescore/MuseScore/blob/master/libmscore/hairpin.cp…
Yep - this is the way it worked with master revision: 6969419
OK, my mistake. I would still have concern about the case I mentioned. Still, if someone wants to implemenet this new feature, it's fine by me.