Clean up default style settings

• Apr 4, 2014 - 15:56
Type
Functional
Severity
S4 - Minor
Status
closed
Project
Tags

GIT commit: 6c5b016

I think that once things seem settled, we should go through all default style settings to make sure they work well together. Some things that off to me right now are lyric height/margin (way too much space), hairpin height relative to dynamics, line text size.


Comments

Bless the heart of whoever first raised this issue. After a less than three weeks of using MuseScore this has become one of my biggest peeve. Unfortunately decades of managing software development have taught me that less than 10% of developers enjoy working on bugs, defects and cosmetic enhancements. This is especially true where the code was produced by someone else. Even those that do enjoy this type of work will only choose to work on those problems with a high degree of visibility. This is why as users we get frustrated with waiting for fixes.

These types of issues are trivial in nature. We just need someone to step up and fix it.

Just to be clear, things have already been drastically overhauled for 2.0, and I am talking about style settings only here. It isn't clear what specifically you might be referring to, and I get the sense you haven't using the development builds anyhow, so whatever frustrations you might have with 1.3 are very possibly already fixed.

But if you have been using development builds and have specific syggestions on style settings you think should be tweaked (eg, default placement of haipins should be 0.5 sp higher to align with dynamics) this would be a good place to list them. Suggestions that don't amount to simply listing a specific style setting and a specific change in default value are best made as forum posts.

Marc,

You were right in that I was using the 1.3 release build. I have since loaded and run with a very recent nightly build. Funny thing though. Many of the style functions and tools I used with 1.3, or workarounds I came up with at 1.3 either do not work as well or at all on the nightly build.

Also it appears next to impossible to apply changes to styles in the user interface to the contents of an existing score.

Don't get me wrong, I love all the features and tools that exist. It just feels like layout, style and other display and layout functions do not seem to work in a consistent manner.

Maybe it is just me and my ability to understand the documentation. Try this. Open or create a complete score with chord names. Use the default styles to complete the score. Then go to the style dialog and try to change the chord name font to Arial and the code name style to include a box around the chord names. Apply it and see if it changes. Next try to select all the chord names and use the change text properties to accomplish the same thing. Nothing happens. The later worked at 1.3 the first method has never worked or I do not know how to make it work.

There is no documentation for 2.0 yet. If you are having trouble understanding how to one one specific thing, please start a thread in the Thecnology Preview forum asking how to do that one specific thing. Separate threads for separate questions. Be as clear as possible.

In general, though, 2.0 is *much* improved over 1.3 when it comes to style. In 1.3, changes to text style never affected existing elements - only elements yet to be created. In 2.0, changes to text style affect existing items as well as ones yet to be created - the same as with just about any word processor, for example.

With regard to chord symbols specifically, these are special, since they are not ordinary text. Changes to text style *do* take effect in both 1.3 *and* in 2.0, although in 1.3, they only take effect after reloading the score. In 2.0, they take effect immediately.

Frames / boxes have *never* been supported for chord symbols in 1.3 (it worked only for unrecognized chords; which are not chords at all but plain text). Support for frames / boxes for chords was just added yesterday (!) in the 2.0 builds.

Text properties never worked consistently with chord symbols in 1.3 because of the very special nature of how they are rendered, so the entire dialog is removed for 2.0. But no loss, because changes to text style now take effect immediately, and you can even assign a different style to certain chord symbols if you want them displayed differently from the default (another very recent addition).

Again, if you have a specific problem with a specific score where you find this is not working as you expect, please start a new thread in the Technology Preview forum with a sample score and the steps you are following. Let's keep this issue in the tracker focused on the specific issue hand: deciding on what the defaults should be for various settings in 2.0.

As things standard, there are two settings only I know need to be changed: the lyric margins, and the relative height of dynamics versus hairpins. But I don't doubt there are others.

Once the integration of Bravura Text is complete, I hope to take a look at this. Dynamics, repeat text, and text lines are among the elements that will need to be examined. For repeat text, we also need to make sure we are using the correct text style to position relative to the left or right of the measure. It seems this was set up at one time but is not currently used.

I adjusted hairpin height a while back, so they should align with dynamics now.

There are still issues with repeat text (see #22572: D.S. & To Coda placed at beginning of measure instead of end) that prevent this from being meaningful to work on.

But now that #25409: Staff with lyrics always has at least 7sp of distance to next staff is fixed, I think we can look at the settings for lyrics. In particular, upper/lower margin in general style and the vertical position in the text style. I'm not totally clear on the interaction between upper margin and text style vertical position. I mean, that they are basically additive with respect to where the lyrics end up being positioned, but I am not sure what the difference would be between altering one versus the other. I could imagine they would have different effects on staff spacing, although currently, this does not seem to be the case.

It seems the lyrics upper margin was consciously changed from 2.0sp in 1.3 to 3.5sp in 2.0, and there is even code in read114() to explicitly deal with this change. I don't understand why this change was made, however. It results in lyrics being further below the staff than before. To make matters worse, it's also the case that even with the upper margins set the same in 1.3 and 2.0, the default text style vertical position of 7sp (true in both versions) results in lyrics already being a little over 1sp lower in 2.0 than in 1.3. As far as I can tell, the 2.0 behavior is correct and 1.3 was behaving incorrectly. 1.3 was completely ignoring the text style vertical position, always setting lyrics just over 6sp below the origin (plus whatever the margin did).

The bottom line is, between these two changes, lyrics are now a *lot* further below the staff than they were in 1.3. Much too far; it is enough to accommodate notes five ledger lines below the staff.

I'm kind of wondering now if the change to the upper margin was an attempt to counteract the fix to apply text style vertical position, but the change in upper margin was accidentally made in the wrong direction. Or maybe the margin change was deliberate - to create a little more room than in 1.3 - but was made *before* the fix to apply text style vertical position, so now it's just too much.

I'm interested to hear any insights anyone else has into these changes. But meanwhile, I propose we change the default text style vertical position to 6sp, which is about what the *actual* default was in 1.3. That allows 1.3 scores to work with no special handling in read114(). We'd also restore the default lyric upper margin for new scores to 2.0sp. So the actual default position of lyrics in new scores would be about the same as in 1.3 - enough to accommodate notes two ledger lines below the staff.

BTW, the fix for #25409: Staff with lyrics always has at least 7sp of distance to next staff means I'll also need to increase the lyric *lower* margin by 4sp to get the same results as 1.3, although we can also re-evaluate that.

To get a better idea of what the desired end result should be, I checked with lots of sources, but didn't learn much. Gould doesn't mention any specifics here. Sibelius, oddly enough, does not automatically increase distance down at all - you have to do it manually. Checking the published literature in many different genres and scores types (leadsheets, PVG arrangements, choral arrangements, etc) I see spacing - both upper and lower margins - is all over the map, often varying from system to system in the same score. Complicating this is the fact that even the ordinary staff distance (with no lyrics involved) differs wildly.

After careful consideration, my best cut at choosing defaults for MuseScore is:

Default text style vertical position of 6sp, lyric upper margin of 2sp, is as good as anything. This will be consistent visually with 1.3 - new and imported scores will appear about the same in this respect.

For lyric lower margin in 1.3 scores, I will add 4sp to the actual value (which defaulted to 2sp), for compatibility. End result: imported scores created with defaults in 1.3 will show 6sp as the lyric lower margin but look the same as they did in 1.3 with 2sp for that setting.

For lyric lower margin in *new* scores, however, my analysis of the literature suggests 6sp is larger than makes sense as a default. So my PR will make it 4sp - one normal 5-line staff height margin enforced below the lyric before the next staff. Many scores won't notice a difference because the staff system distance is already enough. And some scores may need to increase this value. But most should be happier with this as the default.

I just updated the style settings for repeat texts too, so that should be good.

The main thing I can think of offhand that could use an update is tempo text - according to Gould and common practice, these should be bold. I think measure numbers are too high as well. Higher than 1.3, and they get in the way of segnos & codas. I may raise segnos & codas a little too; my previus PR didn't actually change the defaults except for size & alignment. Would be nice if measure numbers and segnos/codas cleared each other by default.

I was also thinking about playing with the alignment of rehearsal marks and tempo. Rehearsal marks could possibly be centered over barlines as we do for coda & segno. Tempo markings at the beginning of the score could be forced to align over the time signature instead of the first note.

Mostly, though, it's a matter of building a score that uses lots of things and see how the defaults work together. I know collisions can't be avoided completely, but there may be opportunities to make better choices - like my example of measure numbers versus segnos/codas. I'll be looking at this soon; would be nice to go into a beta with defaults we don't think we'll need to change.

I'm working on the issues I raised above. It's actually quite easy to force tempo markings to alignh over time signatures if entered on first chordrest of bar that has a time sig. Similarly for aligning rehearsal marks over barline.

One question that comes up for the latter is behavior at the beginning of a system (a very common place for rehearsal marks). Centering over the barline means they occupy more or less the same space segnos/codas want to be, and also measure numbers. I could just let them all collide and have user sort it out, but wondering what others think. BTW, having them detect and avoid each other is *not* an option. I'm just talking about changing the default position of measure numbers, segnos/codas, and/or rehearsal marks when at beginning of system.

BTW, regarding measure numbers,see #19146: Bar numbers incorrectly positioned. Regarding rehearsal marks, see http://musescore.org/en/node/25392 and https://github.com/musescore/MuseScore/pull/837/files.

What I am doing at the moment now with with respect to rehearsal marks at the beginning of the system is to look for a clef within the measure, and if present, align just to the right of it. This keeps the rehearsal mark away from the rest of the train wreck at the beginning of the system, assuming one hasn't turned off display of clefs. It's not perfect, and I'm pretty sure I won't keep it like this, but I did want to see if it worked, and it does:

rehearsal-tempo-marks-3.png

If nothing else, I'd have to force the rehearsal mark after the clef to left align rather than center, to keep it from colliding with the clef. That's a hack on top of a hack on top of a hack, though...

Attachment Size
rehearsal-tempo-marks-3.png 15.16 KB

Personally I don't have a problem with the rehearsal letters being further into the bar rather than centered on the Barline. I would suggest perhaps placing it between the 1st 2 quarters or the 2nd and 3rd rather than directly over the 2nd quarter as that may lead to collisions with changes (chordnames).

Regards,

Good to know. The "standard" for rehearsal marks *not* at the start of a system does seem to be centered over the barline, or in the case of scores with chord symbols, to the left of that even (which you could accomplish by setting the text style to "right aligned").

When you say you "don't have a problem" with the rehearsal letters being further in, does that mean you *prefer* it? Are there major puiblishers you know of who do it that way? I'm trying to find as many precedents as I can.

BTW, if you place the rehearsal mark directly on the second (or third) note, but set it to be right aligned, and/or set it's its horizontal offset to be some negative value, you can get the effect I think you are describing.

Updating templates as per #17386: Templates are outdated will be a great opportunity to visit this.

Meanwhile, regarding tempo & rehearsal marks: I will definitely make tempo bold. I'm happy with my changes for layout as well, but need to figure out best plan for import of 1.3. For unadjusted tempo texts and rehearsal marks, they will pick up new defaults, as for anything else, and hopefully users will thank us for improving their scores automatically :-). For ones with custom text styles, their custom styles will be applied, but layout will be the new layout, which will be good for most cases as well, unless they were setting negative horizontal positions. For ones with user offsest applied, I will probably just clear it, as we do for a number of other element types whose layout changed significantly. Still thinking about this.

@Marc (#16, Max system distance): Funny, I often find it too small! This max value comes into account when a page is not completely filled, to spread systems and fill it (or attempt to fill it).

For the music I mostly deal with (Renaissance music in 2 to 4 parts, not rarely fitting in two facing pages), I don't like two facing pages to be *more or less* of the same length: they should be either both filled up or very different.

But this is exactly what often happens with the current default max distance of 15sp. I find I need to increase it to about 20sp in order to have pages with one/two systems less than the others to fill up completely (in cases where, to my eyes, one/two systems less do not qualify the page as a "shorter enough").

Of course, this might be peculiar to my repertory or my taste...

M.

In bc329eca33

1/ I changed the bracket distance to 0.1sp
2/ I change the computation of % so that the qreal comparison is better (at least on mac) and we don't write unchanged styles (smallstaffsize for example) to the file.
3/ I rounded beamMinLen to avoid the rewriting.
4/ Added noBeamSlope default, it was missing and so we were writing it
5/ fixed the default of figured bass font

FWIW, I didn't really come upon anything that struck me as needing global update when doing my templates yesterday. Some needed tweaking of a parameter or two but always for reasons that really were specific to that template (eg, moving default voltas higher to account for chord symbols in jazz templates).

Status (old) active fixed

Since we've looked at a bunch of these over the course of preparing for the beta (including creating templates), I'm closing this as a general task. If we encounter specific settings to revisit, we can create individual issues for them.