hairpins and dynamics marks

• Jul 24, 2015 - 22:39

Hi, gang!!!

I don't know if this has some easy solution into 2.0.2 version, but with 2.0.0 isn't.

Why not to add an order to the MuseScore internal gnome to put on the right place and with the right size the hairpins between the dynamics marks (p, mf, ff)? ???

I mean, when we input some dynamic mark on the score (whatever it was) and then we add an hairpin, the size and the position of the hairpin starts behind the dynamic mark. So, we have to manually move it with the mouse.

Why not to teach the "gnome" to put it right way? ???

Just an idea.

Greetings!!!

Juan


Comments

It only overlaps if you try starting the hairpin on the same note that has the dynamic. it's designed to work so you start the hairpin on the *next* note, or some other subseqauent note, and end the hairpin on the note *before* the new dynamic. If you do it that way, everything is sized perfectly the moment you press "<".

In reply to by Marc Sabatella

"It's designed to work…" I don't think so. I think that in many cases it does work, but in many others it doesn't (try with attached score, for example), and I think jotape1960's suggestion is such a good one I'm surprised I never thought about asking for it myself. Remember how improved collision avoidance is on the roadmap, but only cases that are especially common will be looked at first? This is probably the single most common collision there is, and an automatic offset is a great idea.

Attachment Size
dynamics-layout.mscz 5.94 KB

In reply to by Isaac Weiss

It *is* designed to work the way I described, and it works extremely well in the majority of cases. Normally, you wouldn't need a dynamic on the start note of a hairpin, because the current dyanmic is assumed to already be in effect and wouldn't need repeating. So it works quite well in these common cases. The case needing a dynamic change right at the start of a hairpin really shouldn't be that common

Even In those cases where for whatever reason you do want a change in dynamic - or feel it necessary to restate the current current dynamic - if you do it the way I suggested, it works perfectly. So the design works very well in the majority of cases. The main real world case where you would really need the crescendo to start on the same note as the dynamic is if that note is a long note and want to make it clear that the crescendo should start immediately, not with the next note. So it is true that in these casses and these cases only, you currently need to apply a manual adjustment. That doesn't mean the design isn't very good for the majority of cases, which work perfectly out of the box.

For these special cases where you need a dynamic and hairpin starting on the same note, automatic adjustment is not a bad idea, although really, why should MuseScore assumed you want to move the hairpin right rather than the dynamic left? And if I *do* want the dynamic ove left, now it's twice as much to fix. That's the problem with automatic adjustments - without controls over how that adjustment is performed, it ends up being counterproductive half the time.

In reply to by Marc Sabatella

Let me drop this in:

Dynamics and hairpins overlap:

DynamicHairpinOverlap.png

If you start the hairpin on the next note, it looks like this:

DynamicHairpinOverlap2.png

This would be good if the crescendo started on the next note, but in this case we are concerned with the crescendo starting on the first note.
In which case I think it should look more like this:

DynamicHairpinOverlap3.png

This is how it looks with a half instead:

DynamicHairpinOverlap4.png

...should look like...

DynamicHairpinOverlap5.png

PS- Sorry for the large images. I didn't think about that when taking the photos.

In reply to by Sean Oliveras

Yes, as I acknowledged previously, this is indeed the special case where it does happen to make sense to make an adjustment. But the current algorithm works well for the *usual* cases. Special casing this situation is no doubt possible, feel free to file a feature request. In principle, it's much like other automatic collision resolution cases that have been discussed, but this particualr one might turn out to be rather easier to implement than some.

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