search

rism-digital / verovio

🎵 Music notation engraving library for MEI with MusicXML and Humdrum support and various toolkits (JavaScript, Python)
https://www.verovio.org
GNU Lesser General Public License v3.0
678 stars 185 forks source link

Clef change size #2849

Closed craigsapp closed 2 years ago

craigsapp commented 2 years ago

The size of clef changes is too small. It is currently 66% of full-sized clefs, but should be increased to 75% of full-sized clefs. Here is an example:

Screen Shot 2022-05-08 at 10 01 32 AM
Click to view MEI data for above example ```xml </titleStmt> <pubStmt /> </fileDesc> <encodingDesc> <appInfo> <application isodate="2022-05-08T10:01:34" version="3.10.0-dev-2bebcfc-dirty"> <name>Verovio</name> <p>Transcoded from Humdrum</p> </application> </appInfo> </encodingDesc> <workList> <work> <title xml:id="title-L9" analog="humdrum:Xfi" type="translated">extract -k 2
```

67% should instead be reserved for cue-sized clef changes.

Measuring the size graphically:

Screen Shot 2022-05-08 at 10 05 06 AM

The problem most like occurs because of this statement on page 7 of Behind Bars:

Screen Shot 2022-05-08 at 9 25 03 AM

The problem is that the following examples in the book all use 75% scaling instead of 67%. Here is an example from page 8:

Screen Shot 2022-05-08 at 10 06 43 AM

And also, here is a brief survey of treble clef changes in late-nineteenth and twientieth century editions (including several computer-typeset editions):

Screen Shot 2022-05-08 at 9 57 15 AMScreen Shot 2022-05-08 at 9 59 27 AMScreen Shot 2022-05-08 at 9 59 00 AMScreen Shot 2022-05-08 at 9 58 41 AMScreen Shot 2022-05-08 at 9 58 22 AMScreen Shot 2022-05-08 at 9 57 55 AMScreen Shot 2022-05-08 at 9 56 48 AMScreen Shot 2022-05-08 at 9 55 45 AMScreen Shot 2022-05-08 at 9 55 30 AMScreen Shot 2022-05-08 at 9 54 56 AMScreen Shot 2022-05-08 at 9 53 45 AM

All are using 75%. As a comparison, here is verovio which is using 67%:

Screen Shot 2022-05-08 at 9 59 35 AM
rettinghaus commented 2 years ago

So why not just use --clef-change-factor?

craigsapp commented 2 years ago

Because 75% is 100% correct.

craigsapp commented 2 years ago

Was last correct in version 3.2:

Screen Shot 2022-05-08 at 12 40 52 PM
lpugin commented 2 years ago

From @craigsapp's examples and considering the incoherence in Behind Bars it looks like it would make sense to revert the default to 75%. Finale also has a default of 75%, and so seems to have LilyPond - looking at some scores. Only Dorico has a default of 2/3. But as pointed out by @rettinghaus we have now the option --clef-change-factor which can be used to set it to any less common value.

craigsapp commented 2 years ago

Only Dorico has a default of 2/3.

As Dorico is developed by English programmers, I suspect that they used the 2/3 value mentioned in Behind Bars, which is obviously a mistake since it does not match the example. The 66% clef looks too small to me, which is why I checked into it and noticed the inconsistency in the Behind Bars description versus examples. And 11/11 of the editions I looked at from a variety of publishers emphasize the point since they were all at 75%.

-=+Craig

rettinghaus commented 2 years ago

It seems that @craigsapp is pretty confident with his 75%, but in the scores I checked it is more like 80%. Also in classic printed material often G and F clefs don't show the same ratio, with F clefs scaled larger, more at approx. 90%. I went with Gould here because she gives a precise number (although I also think that this is too small). Another possibility would be to use the small clefs coming with the SMuFL font, which maybe would bring a more consistent look. But then we probably would give up some flexibility we have right now, e.g. with ottava clefs. I've never seen the latter as changing clefs in real life, but maybe someone has an example by hand? On the other hand, in early modern prints changing clefs were not printed smaller, so going with the standard size (glyphs) seems to be fine when handling mensural notation/clefs. One last point: thinking about this, I would expect that when selecting a specific clef (by @glyph.name or similar) Verovio would show this clef at 100% size, but right now it gets scaled down (when it's within a layer). A per clef scaling mechanism could be implemented by adding support on @fontsize. Any opinion on this?

craigsapp commented 2 years ago

I went with Gould here because she gives a precise number (although I also think that this is too small).

I repeat that that number is obviously incorrect, which is why it is too small.

It seems that @craigsapp is pretty confident with his 75%, but in the scores I checked it is more like 80%. Also in classic printed material often G and F clefs don't show the same ratio, with F clefs scaled larger, more at approx. 90%.

I don't care what precise default value is as long as it is noticeably larger than 66%. 66% looks unnatural, and that is why I looked it up in Behind Bars and subsequently noticed that the 2/3rds scaling she cites was a mistake.

The Liszt clef you cite is also does not have uniform vertical scaling: the top half is closer to 100%, and the bottom is perhaps 80%, making the average 90%:

Screen Shot 2022-05-10 at 7 29 48 AM
lpugin commented 2 years ago

It seems that @craigsapp is pretty confident with his 75%, but in the scores I checked it is more like 80%.

If you want to have 80% as a default, that is fine with me.

lpugin commented 2 years ago

We can have a new issue based on https://github.com/rism-digital/verovio/discussions/2852 when it is clarified