Dynamics on Vocal Lines

• Jan 17, 2014 - 06:59

I am using version 2 revision 30e0623. I find that dynamics are placed below the staff universally for all parts, however for vocal lines, this is incorrect. They should be above the staff. Is there a setting somewhere that will change this behavior? In my mind there should just be a switch in the Staff Properties that says if the default position should be above or below.

I have also found a bug in that after I have gone through the entire score and repositioned the dynamics above the staff, when I create a part, it places them all back in their default position so I have to do all of it again.

Steps to reproduce:
1) Create a score with at least 1 vocal part
2) Add some notes
3) Add some dynamics to the vocal line
4) Move the dynamics above the staff
5) Create a part for the vocal line

After step 5 you can observe that the dynamics have moved back to their default position.


menu->Style->Text...->Dynamics->Vertical, set to some negative value, like -1 or -2
Or rightclick->text properties->uncheck styled and then change vertical to some negative value.

The Style setting will change the default position for dynamics globally. There is unfortunately no way to have it set one way for vocal staves but another for other staves. However, you *can* create a custom style (via the "New" button in Style / Text) and easily apply it to all the dynamics in the vocal staff in a single operation (right click one, select / all similar elements in same staff, then use dropdown in Inspector.

As for the bug report: I can confrim this happens for manually positioned dynamics. However, it does work as expected if you use the style method.

Thinking about it further, I'm not convinced that manual positioning *should* be preserved between score and parts. After all, one of the main reasons one might resort to manual adjustments in a score (as opposed to using a Style) is to avoid collisions that realistically might not occur in the parts. For example, a collision between markings below one staff might appear to collide with markings above the next staff, but that won't be the case in the part, since the other staff won't be there. Also, the layout will likely be very different in terms of spacing and number of measures per system, and hence where the system breaks occur. So many of the most reasons for needing manual adjustments won't hold. And in any event, it's definitely the case that manual adjustments made to the score *after* parts are generated don't and shouldn't affect the parts, nor should adjustments in the parts affect the score.

I could imagine a case being made that maybe parts should at least inherit manual adjustments already present in the score when the parts are generated but then the link should be broken. Probably a trivial change to the code, but again, I'm not convinced it's actually the right thing.

BTW, there are a number of existing issues in the tracker (see Issue tracker in menu at right of this page) dealing with similar cases of changes not being reflected that should, or vice versa. Also a few bugs involving changes to manual position not being preserved - or being misapplied - on save/reload. So do expect to run into other issues in this area.

In reply to by Marc Sabatella

My main experience in this area comes from years of using Finale, before I discovered MuseScore. In Finale, by default everything is linked to the score. If you change an object in a part, then it immediately becomes unlinked. They also have a right-click option to relink an object back to the score, which can be very useful.

To me, this is a logical way to handle this. My personal opinion is that nothing done in a part should ever go back to the score. The score should be seen as the master copy of everything. If you want something different in a part, then it should become unlinked and be independent of the score from that point forward (unless you relink it again).

If some things are linked to the score and other are not, and some things done in a part go back to the score, and others do not, it is going to be very difficult and frustrating for users to know what is going on and to get what they want. I would strongly recommend that we try to move in the direction of everything being linked until the link is explicitly broken in a part. Anyway, that is my 2 cents.

In reply to by brianr0922

You wouldn't even expect note changes (G to A) in a part to affect the score? I would, and my recollection is that this works in Finale too. Similarly, adding notes in a part should reflect back to the score, and I recall Finale doing that, too. I'd also expect adding dynamics, slurs, etc to go back to the score by default. I'd also expect that editing text would go back to the score, except for the part name in the upper left since that doesn't even appear in the score.

Now, *position* changes should indeed be local by default. But even so, you don't actually want position changes to *totally* break the link. Even if you manually position a dynamic marking (say) in the part, you'd still want it to be the case that if you replace that dynamic with a totally different one, this would be linked. What this means in practice is that the link should still be present, it just wouldn't be honored for *position* adjustments.

This to me seems a very natural and expected distinction: changes to *content* are always linked, changes to *appearance* not.

Now occasionally you *might* actually want to completely break the link so that even content changes are not linked - like if you actually want the part to have "pp" where the score has "ff". This is, to me, very much the exception - it should be quite rare. But indeed, there will be cases where the need to actually break the link may arise. I've requested this, hopefully it will be added some day. Meanwhile, though, you can get markings that appear in one but not the other by setting the marking invisible where you don't want it. So you'd add both the pp and the ff, but set one invisible in the score the other invisible in the part.

I too came from Finale, but I don't remember the linked parts facility quite as fondly. I liked the idea, but not the implementation so much. Whereas my impression is that, bugs aside (and there are plenty of them to be sure), the linked parts facility as implemented in MuseScore actually works very well - almost everything does exactly what you want it to by default. You almost never need to override anything. My recollection with Finale was that I was constantly undoing and hunting for the modifier key to make Finale do something other than the default.

In reply to by Marc Sabatella

Yes, I think you are exactly right. Content changes should be reflected in both places, but position changes should not. I too remember spending a lot of time in Finale linking and unlinking and relinking to get things to format the way I wanted. MuseScore's formatting and avoiding collisions is definitely superior in this area.

BTW, thank you for the tip about creating a new style for dynamics on vocal lines. I had not noticed that little new button. It makes things a lot easier.

However, I think I found another bug related to this. I selected one of my dynamics, and then selected all similar elements on the same staff. (I checked and they were, in fact, all selected.) I then changed the style to my new style, but it only worked for the first element that I had originally selected. I have selected other types of text, like lyrics, and chagned the style and it did effect everything, so I don't know if this bug only applies to dynamics, or if it is a problem with custom styles that a user creates. I will do some more experimenting to try to find out.

In reply to by Marc Sabatella

I did use Text Properties (which I would expect to work as it does on most other types of elements). So to me this is a bug. I tried it with inspector, and as you indicated, it does work fine there. For me, the bigger bug is that changes in the text style do not get saved, either in the score or the parts. I go through and change everything so it is exactly as I want it, save the document, and when I reopen it, everything has gone back to its original style. For sure this must be a bug. Should I put it in the Issue tracker? Is anyone allowed to post bugs there?

Speaking of bugs, there also seems to be one related to lyrics. In the score you can select one lyric, and use select to select all the rest of the lyrics, then change the text style. In parts, if you select one lyric and try to use select to get the rest, nothing happens. It doesn't select anything. Is this another bug that should be reported?

Further to our discussion about what should be linked between score and parts and what should not, I think this is another area that should be linked. If a user completely changes an element from one text style to another, they probably want that to be reflected in both score and parts. I know there might be specific instance where that is not the case, but I think the vast majority of the time, if people are making a change like this they would prefer for it to be global. What are your thoughts?

In reply to by brianr0922

I agree it's a bug that Text Properties changes don't seem to affect multiple items if multiple items are selected. And yes, anyone can post to the tracker, so you might as well do it. Include a clear test case and precise steps to reproduce.

I am not sure what you mean about changes to text styles not being saved, though. They are for me. Are you sure you're not seeing the effect of this: #22620: Change to linked part does not mark anything dirty? I suspect you are not actually saving your change when you think you are. Also see #23380: Manual position of rehearsal marks & tempo text in parts not preserved on save/load. If you think you are seeing something different from one of these, maybe post your score and steps here before posting to the tracker for confirmation. Could be something unique to your score, or something you are doing wrong, or just me not understanding what you are describing.

The question of whether style changes should be linked or not is tricky. There are definitely some aspects of a score you most definitely do *not* want linked. That's why there is a whole separate "Style for parts" option in Edit / Preferences - to allow to specifically specify the style to be used for parts on the expectation that it will be different from the score. So it would possibly be confusing to have some style parameters linked and others not. Also, consider - if the styles are linked, then changes to style in one part, after propagating to the score, will then also propagate to all parts. This is very likely *not* what is intended. The rule could be, changes made to the score propagate to parts, but not vice versa.

Overall, I'd say there is definitely room for improvement in how all this works. But in my mind, I'd much rather have too little linked than too much. If I have to duplicate work between score and parts, I'm not worse off than 1.3. But if I find change to one have unintended effect on the other - especially if I can't easily get around it - that's more troublesome.

Ideally, I think the parts shouldn't have a "full" style. They should inherit the score style for most things, with "style for parts" just being an override for selected things. Not sure exactly how that would work, though. Anyhow, I expect there will be refinements to this mechanism over time, just as was the case for Finale and for Sibelius (whose design both Finale and MuseScore largely copied).

In reply to by Marc Sabatella

Regarding linking of styles to parts, I think that your last comment is how it should work. Changes to style in the score effect all of the parts, but changes in the part cause that element to become unlinked and do not effect the score. If you create a score and go to all of the trouble of changing styles to be what you want, it is a real annoyance to have to do it all again in the parts. A good example of this is dynamics in vocal parts (where this discussion started). No one wants to have to change all of the dynamics in the score and then go through and change them all again in the parts.

Having said that, this entire problem would go away if there was simply a property in the definition of each instrument that indicated if dynamics should appear above or below the staff (and then set the Y coordinate for both in the effected style).

For the bug I mentioned about styles not being saved, I have attached an example. If you open it, you will see that the dynamics for the soprano line all appear below the staff. I added a new style called 'Dynamics Vocal' that places them above. Simply right-click each of the dynamics, go to text properties, change the style to 'Dynamics Vocal', save the score, and close it. When you reload the score, you will see that the style for all of them has reverted back to 'Dynamics'.

I am using build 30e0623. If you can verify that you also see this behavior, then I will report the bug in Issue tracker.

Attachment Size
test.mscz 2.11 KB

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