[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: possible bug?

From: E Appeldoorn
Subject: Re[2]: possible bug?
Date: Sat, 25 Dec 2021 20:02:00 +0000
User-agent: eM_Client/8.2.1659.0

Thanks Lukas (and others)
but after applying \override Score.SpacingSpanner.strict-grace-spacing = ##t the score still gets squashed and mangled. It is a larger and complex score (Thanks to B Britten) and sometimes a solution in one bar creates an error in an other. I still lean towards it being a bug.

PS I did not expect to get stuck, but it seems that the end result in this score leaves to be desired.

------ Origineel bericht ------
Van: "Lukas-Fabian Moser" <>
Aan: "E Appeldoorn" <>; "" <>
Verzonden: 25-12-2021 20:44:22
Onderwerp: Re: possible bug?

And one addition:

I did try the options you then gave me. (context \score \override 
SpacingSpanner.strict-note-spacing = ##t and also \override 
Score.SpacingSpanner.strict-grace-spacing = ##t)

The relationship between those two settings is not at all obvious from the 

But in fact, if I read the source correctly,

strict-grace-spacing = ##t

is strictly weaker[1] than

strict-note-spacing = ##t.

So, in your use case: You can forget about strict-note-spacing, since the 
behaviour that interests you is controlled by strict-grace-spacing, and 
strict-note-spacing does the same thing *and more*.


[1] For future reference: The two booleans are translated in 
lily/ into

float_nonmusical_columns_ for strict-note-spacing
float_grace_columns_ for strict-grace-spacing

which both are used

1) in lily/ treat grace columns as loose if 
_either_ of the two properties is true,
2) in lily/ handle actual non-musical columns; here, only 
float_nonmusical_columns_ is used.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]