Editing a dynamic’s text disables it

• May 31, 2017 - 18:20
Reported version
2.1
Type
Functional
Severity
S3 - Major
Status
closed
Project
MuseScore

When editing a dynamic’s text, e.g. change from 'mp' to 'mp espressivo' or from 'p' to '(p)'¹, the velocity is reset to 0, and the dynamic is therefore disabled.

One has to manually remember the original velocity from the inspector and reset it there after the text change, or (mass-)edit the .mscx file.

¹) which, interestingly enough, cannot be done by the “surround with parentheses” shortcut

Comments

• Jun 1, 2017 - 19:32

I think this is because we compare text against a fixed list to find which type to assign, and assign "unknown" if we don't see a match. This also causes the status bar and screen reader to report same. We should instead keep any existing type.

Reply

• Jun 2, 2017 - 15:20

Hm, but if you add “mp” then change it to “p something” it should of course not keep the mp velocity… this may require some more thought.

(But then, if you do this, you’re doing something wrong — but then, on the other hand, users are stupid and will do this all the time, even if documented.)

Reply

• Jun 2, 2017 - 16:09

True, people will probably try to change from one proper dynamic to another expecting the velocity to change, but this feature is so you can add something like sempre or memmeno to it. I'm sure you already understand this though. I've not seen anyone comment that the velocity didn't change automatically in tree forums.

Reply

• Jun 4, 2017 - 22:06

Hm, but if you add “mp” then change it to “p something” it should of course not keep the mp velocity… this may require some more thought.
This would be true in some cases, but say "something" = "dolce" or "espressivo". Then the velocity would not change.

Reply

• Jun 4, 2017 - 16:49

This "bug" does not happen if you just change the size. p in 10 point sounds the same as in 12 point (unlike in version 1 BTW). And I think the small size dynamics is preferable to the bracketed dynamics (and very commonly used).

I also think the wide variety of possible "somethings" combined with the wide variety of standard markings will make this difficult to fix--if it needs fixing. I have used two separate dynamics texts in these situations and placed them accordingly, then adjusted velocity if necessary (rarely).

Reply

• Jun 5, 2017 - 18:13

This issue is currently on the "hit list" for 2.2, but as I mentioned above, I don't think there really is an issue here, except for the status line (and I have a fix for that). I'm not even sure about MusicXML - my read of the spec says we are currently doing this correctly as well.

If there is more that needs doing I'm happy to include it in my PR. But as I said, I think it is *good* that we don't mess with the semantics of the marking just because because you've edited the text. We can't be in the business of applying AI algorithms and so forth to figure out what text might correspond to what dynamics.

As a user, I'd expect this to work more or less like tempo, where you can enter a tempo marking then change the text to "allegro" or whatever and keep the existing semantics. Yes, we do have a special "follow text" semantics for a very limited vocabulary: "note = number", and the user has control over this in the Inspector. I don't really see the need to go that far here though.

Reply