problem with manual position changes of dynamics

• Nov 22, 2019 - 15:23

I have an ongoing problem with musescore (even with the latest version). It has to do with the manual re-positioning of dynamic markings on a score, when a lined dynamic marking (e.g, a line crescendo or diminuendo) is placed close to, or leads to and from, a shorthand dynamic marking (fp, pp etc). This re-alignment is needed at times to give space for other articulations in any given bar or to tidy up the score presentation.

To do this, I have to choose one of the existing indications on the score and move it to the desired position, which then allows me to move all the other markings to match in that bar. However, there is no default system for moving such things. Sometimes I must click on the shorthand symbol (fp, pp etc) and other times on the line marking. It's inconsistent and seemingly random, not only on the same part from one bar to the next but also across different parts, even when the dynamics involved are the same for all voices. And when there are many markings involved, it wastes a lot of time across large scores (e.g, symphonic or long chamber music scores) having to figure out which symbol will activate the position change. Anyone else have this problem or know how to solve it. Alternatively (musescore programmers), can a fix be included in the next version update?


Comments

Hairpins and dynamics staying lined up is by design. Hairpins are also extended to have the point close to the dynamic as some publishers have made a standard practice. This is the most common expectation and it's easier to undo this than to do it. I have also noticed that moving a hairpin on one staff sometimes causes the hairpin on another staff to move. This makes absolutely no sense. The workaround in both cases is to hold the alt key while moving the hairpin. This will turn off auto placement, prevent the hairpin from forcing the dynamic to follow it and stop being affected by hairpins on other staves.

I do believe the hairpins on other staves moving is a bug, but I'm not sure if it has been reported.

Alt+drag disables autoplace for the element as mentioned, also pressing "=" does.

If that doesn't help, please attach your score and tell us where specifically you are having trouble, so we can understand and assist better.

In reply to by Marc Sabatella

Hi. Thanks for your reply, however this is not the problem. I've taken a short half minute video of the issue but despite several attempts I cannot seem to add a video on this thread as a file attachment, so hopefully I can explain via the photo instead. (If not, let me know if I can email you the video elsewhere).

In the attached photo, I have placed the cursor in the 2nd last bar. Here you can see a shorthand mp followed by a lined diminuendo and then a shorthand p marking. It has the same in the following bar in the same part.

So I want on occasion to re-align these markings a little higher or lower in certain bars. To do this I must of course grab one of the symbols and move to the desired position.

The problem I encounter regularly, and which is VERY time-consuming particularly when done on large scores, is that the program doesn't have a standard choice for moving multiple symbols. So in this example, in the first bar I mentioned, I need to randomly click on each symbol hoping to find the one which will allow the movement to occur. It might be the mp, or the lined dim or the last p marking. But it's a guess every time. And when I get it finally in one bar, the next bar will activate on one of the other markings, not the same one. To be clear, it might be the line dim in bar 1 but to do the same task in bar 2 then it's the mp instead.

It happens also that it can be the exact same markings in two different voices in the same bar, e.g., a viola and a cello part. The same problem occurs there as well. It's entirely random and highly annoying.

I would love to have an in-built option such that the first dynamic marking in a bar (or the last - it doesn't matter which is designated by the musescore programmer), when it gets moved, activates an equal shift in physical placement for all the other dynamic markings in that bar. But most important...it should be constant throughout the score, not random guesswork as it presently is.

Attachment Size
Screenshot_20191123-124938_Gallery.jpg 361.91 KB

In reply to by Ozby756

Are you trying to keep them algined, or trying to make them not be aligned?

If the goal is to keep them aligned, and you wish to move them further from the notes, it also works to simply one of the symbols, and the rest should follow.

If, on the other hand, the goal is not to keep them aligned, then best to disable autoplace for the element(s) you are moving. Similarly, disable autoplace if the goal is to move any of the aligned elements closer than the default. Trying to manually move elements that autoplace is trying to align is going to be problematic indeed, but I don't see how to know what the actual goal is. If you have some specific case where you believe the results are different from what could reasonably be expected, feel free to attach a score and precise step by step instructions (results are not random, they should be deterministic, the algorithm is applied left to right).

BTW, while you can't attach a video here, there are lots of places where you can - YouTube, Dropbox, Google Drive, etc - so you can always just upload there and then paste in the link here.

Also, if you want to attach an image, instead of taking a picture of your computer screen, using the image capture tool (camera icon on toolbar) built in to MuseScore. Much easier, and much better quality too.

In reply to by mike320

What is happening is that autoplace doesn't want them closer, so it disallows the action. For 3.1, I implemented a facility to automatically decrease "min distance" for the element being moved, thus allowing it to get closer to the skyline than it otherwise would, or even move into it. But what doesn't happen is automatically decreasing the min distance for the other aligned elements, so they are asking to be placed further away. And thus, the layout algorithm has conflicting information to work with - one element saying "I want to be here", and another saying "I need to be here". Somehow I guess we need a way to resolve that conflict, but for now, the solution is, disable autoplace for the elements in question.

In reply to by Marc Sabatella

Thanks for both your inputs. Marc, I agree that the result needs to align. But to be a bit clearer in response to your message, the results themselves are not random placements; rather it's the choice of which element to grab and move (that which will activate a similar change in at least one other dynamic element) which is presently random. And it's that which is highly time-consuming.

As for the goal, I find that on occasion the score spreads itself a little too much and I have found that once I have re-adjusted the placement of aforementioned dynamic elements, the score becomes more compact across the staves attached. Vocal parts in particular have a tendency in default setting to be a little too spread (top to bottom) with the result that from a performer's perspective one has to toggle the eyes a little too far between pitch and text, particularly when dynamics are placed in-between. But it can also be problematic in instrumental parts, because when performance instructions (rubato, con vibrato etc) are added above any set of pitches in any given part/bar, the dynamics in the voice above can often then sit too close to those instructions. So in such cases I also manually adjust so as to avoid ambiguity for any musician/conductor looking at the score.

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