Can not change hairpin end beat with mouse
Hi.
I'm trying to have a crescendo and a decrescendo hairpin in a measure.
The first starting on beat 1 and ending on beat two and the second starting on beat three and ending on beat four.
I can visually move them around, but that does not actually take effect, and the status bar at the bottom still says that the crescendo hairpin still ends on beat 4.
Using the latest nightly on Windows.
Thanks.
Comments
Well, shift + left arrow key and shift + right arrow key do work, but why can't one move these with the mouse as one does with slurs, isn't that way more intuitive?
I guess this will have to be turned into a feature request then.
Thanks.
Lines in MuseScore are almost all extended via shift+left/right - this includes hairpins, pedal, voltas, other text lines, etc. Slurs are the only exception, because they - unlike other lines - are attached to specific notes and can thus cross voices or even staves.
Allowing one to extend other lines by mouse would be a bad idea in my opinion because then you'd have the same problem we currently have with dynamics - every time you try to fine tune the visual appearance, the attachment would potentially "jump" to another place unintentionally.
Yes, the issue with the dynamics is annoying as well, why doesn't it just stick to where one first laid it allowing the user to shift things around as much as needed?
If that would be sorted, then the above wouldn't be a problem either.
These are the same issue. The very thing that annoys you about dynamics is what you are asking to now be annoyed with for hairpins as well :-). I would prefer to annoyed by neither. I could imagine maybe something like allowing the "Alt" key while dragging to tell MuseScore you want to change the endpoint.
But for the record, this is why dragging is simply not the recommended way to adjust things, period. Use the keybaord or the Inspector for more precise control and to avoid that nuisance with dynamics.
I think it's multiple issues we are talking about here, which, if all addressed accordingly, would make for a much more intuitive user experience.
Who wants an unintuitive notation software UI anyways?
The "same issue" I am referring to is, whether or not dragging something with a mouse should autoamtically change its attachment point. it seems that occasinally this is what one might want, but other times, it is not. The case at hand being, you expected dragging a hairpin endpint to change its attachment, but you also apparently expect dragging a dynamic to *not* change its attachment. Unfortunately, different people will have different expectations at different times, and it's impossible to accurately predict what any given user might happen to prefer in any given situation. So I feel it is best to be consistent - either always have dragging change attachment, or never. And I personally would prefer it be "never", or at msot, continue to make an exception for slurs for the reason I mentioned, although I'm not crazy about that either.
Certainly there must be a better way.
Perhaps everything should change its attachment point if double-clicked on, but not change its attachment point if just single-clicked and dragged?
I think that's what I was trying to do anyways.
I think that'd be the best solution. Double-click and drag to change attachment, but single click and drag to merely change location but not attachment.
But… single-clicking a hairpin simply moves its location without changing its shape. And double-clicking a dynamic enters text edit mode.
I don't know then, maybe a triple click then? :D (just kidding, but no, seriously, there must be a better way. I just don't have time to think of a better one at the moment, I'll leave that up to developers to think about.)
I agree it's worth thinking about. Normally, keyboard modifiers are used to differentiate things like this - click versus shift+click versus ctrl+click, or drag versus shift+drag versus ctrl+drag, etc. Since these already mean something else, as does shift+ctrl+drag, that's why I suggested "alt" above. but that's not ideal either, as on some operating systems, alt+drag drags the current window.