hairpins, cresc./dim. redraw incorrectly across pages
If a hairpin or dashed cresc./dim. is add in continuous view and the hairpin or dashed cresc./dim. crosses a page boundary then they are drawn incorrectly after changing back to page view. The attached file shows the effect. Files of this nature may display incorrectly in Songbook as well, or may not even open.
| Attachment | Size |
|---|---|
| Hairping,_cresc_dim_error_demo.mscz | 11.24 KB |
Comments
in continuous view: select measures (eg. 15 - 21) double click the hairpin in the palette
You have used the hairpin incorrectly. Or rather have extended it incorrectly, using the mouse-drag rather than select and then using shift-left. Se https://musescore.org/en/handbook/edit-mode
In reply to You have used the hairpin by Jojo-Schmitz
The problem here is the wording in the manual. I have seldom been concerned with finer control and hadn't read to the end of the list where the keys for changing the anchor position are located. I suggest the wording should be changed to something like:
Lines and similar elements, such as slurs, arpeggios, brackets, and hairpins display handles and may display anchors in edit mode. A slur, for example, looks like this:
I suggest a change of graphic to a hairpin with appropriate change in previous sentence, or adding a second graphic of a line (e.g. hairpin) with an anchor.)
To change the position of an anchor use shift right arrow or shift left arrow. To alter the shape of the line, click on a handle and drag it or, for finer control, use one or more of the keyboard commands listed below.
The keyboard command for changing the anchor should be removed from the list because it is not intended for changing the shape of the line.
In reply to The problem here is the by gregm
Well, https://musescore.org/en/handbook/hairpin have been amended slightly to mention shift-left rather than mouse-drag
In reply to Well, by Jojo-Schmitz
The change looks good.
In reply to The problem here is the by gregm
I just updated https://musescore.org/en/node/35981/revisions/view/202621/209961 based on your suggestions. Better?
In reply to I just updated by Isaac Weiss
This change looks good as well.
However, independently of manual changes some thought should also be directed to consistency of behavior. If you drag a dynamic mark you can change both its location and its anchor, something that I do often because dynamic marks consistently land on top of lyrics and I have to reposition them for legibility. Although I perhaps should have realized that the lack of change in the anchor was a problem with hairpins, I somehow assumed that the behavior of the hairpin would automatically adjust to its endpoints. My suggestion is that the anchor for hairpins should follow changes in the hairpin endpoints that exceed the bounds of the the measure in which it was defined.
A word of caution on that point, however. The way that the anchor follows repositioning of dynamic marks is sometimes an issue. Letting an anchor follow the horizontal change of a dynamic mark is ok, but vertical changes (shifting from staff to staff) is not. I sometimes need to position a dynamic mark below the lyrics, but it is difficult because the anchor changes staff and ultimately alters the playback. I mention this issue because if you reprogram the behavior of a hairpin so that the anchor follows horizontal changes in its length (a good thing) you should make sure that vertical changes are disallowed.
Ultimately, it would be nice to have a optional property within the inspector that either locks or unlocks an anchor such that changes in handle position illicit appropriate changes in anchor positions.
In reply to This change looks good as by gregm
Instead of manually adjusting dynamics to avoid lyrics, consider just changing the default text style for them so they appear above the staff, which is the standard for vocal music anyhow. Right click any lyric, Text Style, change vertical position to something negative.
In general, I dislike how moving dynamics changes the anchor and find it far more trouble than it is worth. But I have a feeling I'd like it if mouse movement *did* change anchor for lines (maybe requiring Shift or whatever for fine adjustments).