Editing dynamic text - odd behaviour

• Feb 1, 2020 - 17:12

I am trying to set up a custom pallet that has elements within square brackets so that I can use these to indicate editorial changes in a score. When I was adding square brackets to a dynamic marking I found some odd behaviour. The following screenshots show the score alongside the inspector and demonstrate what I found.

  1. Add a dynamic to a note
    Clipboard01.png
    Note in the inspector that the text italic button is shown depressed

  2. Click on the dynamic to put it into edit mode and add square brackets.
    Clipboard02.png
    Note that the brackets are italicised.

  3. Click on the italic button
    Clipboard03a.png
    Note that nothing has changed in the score, the brackets are still italicised.

  4. Click on the reset to style default button
    Clipboard04a.png
    Note that the Italic button has been reset to ON, the bracket is still italicised as before but the "mf" has been italicised (more italicised?)

  5. Click on the italic button
    Clipboard05a.png
    Note that the mf has been reset to its previous original italisation and the brackets are now not italicised.

That final state is what I want, but the sequence to get there was rather difficult to find.

Also I find the italicised status of dynamics is confusing. From the above shots, it seems I start with the dynamic italicised (based on the status of the italic button). Then after step 4 I have the dynamic more italicised. Then after step 5 I return to the original visual status but with the italic button up. Is the font used for dynamics an italicised font, so that italic button should not be shown depressed when the dynamic is first entered, or is the final status of the italic button lying?


Comments

In reply to by Shoichi

Indeed I do get that. Thanks for reminding me about the text bar. My first thought is always to reach for the inspector to change how something looks.

But it does not explain the odd behaviour I described where it seems possible to apply "double italics" and to have the same appearance with and without the italics button pressed. After a bit of experimenting with the text bar I find that this also shows similar odd behaviour. Double click on a dynamic and highlight the text. The italic button on the text bar shows as pressed. Click on the italic button so that its state changes to "up" and you will see nothing changes in the score. Click again on the italic button so that its state is "down" and the dynamic changes to "double italic". Click again so the button is "up" and the dynamic reverts to its original appearance. As with the inspector, you can get "double italics" and also have the same appearance with the button showing "up"or "down", which is confusing.

Step 3: you are still in text edit mode. Changes to the complete text settings in the inspector at that moment are non-functional.
The problem/confusion is that those fields should be disabled in the inspector when going into text edit mode, but they currently aren't.

In reply to by jeetee

The difference between "Edit" mode and "Text edit" mode is not very clear (at least not to me). The handbook says:

"Edit mode allows you to perform a wide range of editing operations on individual score elements, such as:

  • Adjust the length and shape of slurs, lines, barlines etc.
  • Add, delete and format text in text objects.
  • Adjust the position of most score elements (but not text)."

And

"Text edit mode allows you to add or delete text, and apply formatting (e.g. bold, italic, underline etc.) to individual characters."

Both entries say the mode allows formatting text in text objects with the only seeming difference being that text edit mode allows formatting to be applied to individual characters. Neither of the entries mentions the inspector in the context of formatting text.

The instructions on how to enter Edit mode and Text edit mode seem to overlap.

"Enter edit mode
MuseScore versions 3.4 and above
For lines, hairpins, slurs, note-stems, note-beams, and barlines, use one of the following methods:

  • Click on an element.
  • Right-click on an element and, from the menu, select Edit Element.
    For other elements, use one of the following methods:

  • Double-click an element.

  • Click on an object already selected (text-based objects only).
  • Right-click on an element and, from the menu, select Edit Element. "

Or

"Enter/exit text edit mode
To enter Text edit mode use one of the following methods:

  • Double click on an existing text element.
  • Right-click on a text element and select Edit element.
  • Click on a text element and press Ctrl+E (Mac: Cmd+E)."

So that seems to me to say that double clicking or right clicking and selecting Edit Element gets you into Edit mode and also gets you into Text edit mode, but those two modes are distinct and have subtly different behaviours.

But returning to the main issue, it seems the changes to the complete text settings in the inspector are functional while in text edit mode but in a strange way. I am currently experimenting to understand the effects of different combinations and orders of setting and unsetting italicisation in the inspector and the text bar, but I have not yet got to the bottom of it. It seems that the inspector and text bar can show different states at the same time and some combinations/orders of clicks result in a dynamic that is identified as italic or not italic, but with no difference in appearance, or a dynamic that is "double" italicised, and all of those states are preserved on saving and reloading. I will report back when I understand the oddness of the behaviour a bit better.

In reply to by SteveBlower

Text Edit Mode == Edit mode for a text element

Feel free to further dig into what partials might seemingly do have an effect when changing text settings in the inspector during test edit mode; just be aware that it isn't supported and the UI being enabled currently is a bug.

In reply to by Marc Sabatella

Is that known issue really the same thing? The changes certainly seemed to stick. I could save and reload after each step and the appearance and status in the inspector was retained (i.e. the same as before the save). And does that known issue account for

a) the "double italicised" dynamic as seen in screen grab 4 and

b) the states of the italics button in the inspector and text bar disagreeing and

c) the possibility of getting to a state where the inspector does not reflect the actual state of the dynamic's italic status as seen in either screen grab 1 if the dynamic is not really italicised or 5 if it really is italicised?

Or are these new and unexplored issues? I am very happy to explore them if it contributes to finding a fix, but I would prefer not to waste my time exploring something that is already under investigation. I haven't found anything in the issue tracker that seems similar to the behaviour I am describing, but the issue tracker is a bit of a maze and there may be something there.

In reply to by SteveBlower

I was only specifically referring to the one particular aspect of what you were describing. There is a little much going on in the thread for me to follow completely - I'm a bit jet-lagged from my trip to the FOSDEM conference!

But I can say there is nothing particularly unusual about the Inspector and text toolbar disagreeing, they are showing different things. One is showing the state of the text element as a whole, the other is showing any overrides applied to particular characters within the text.

Do you still have an unanswered question? Please log in first to post your question.