Hi, Here is a more minimal example illustrating your problem:
```
\version "2.24.2"
{
\scaleDurations 1/2 c'1
\scaleDurations 1/3 d'1
\scaleDurations 1/5 e'1
\scaleDurations 1/7 f'1
\scaleDurations 1/11 g'1
\scaleDurations 1/13 a'1
\scaleDurations 1/17 b'1
\scaleDurations 1/19 c''1
\scaleDurations 1/23 d''1
\scaleDurations 1/29 e''1
\scaleDurations 1/31 f''1
\scaleDurations 1/37 g''1
}
```
The underlying issue here is that you use lots of "complicated"
multipliers, with high denominators. LilyPond needs to represent
each point in time in an exact way, which it does using fractions.
However, because the denominators you use are sufficiently large
and have sufficiently few common prime factors, the denominator of
the fraction needed to represent a moment in your score gets huge.
In my example above, the product of primes up to 37 has the order
of magnitude of ten thousand billions, or two at the power 43.
Programs often use a fixed number of digits to represent integers,
for efficiency reasons. At some point, the computations overflow the
number of digits that is being used, and everything goes wrong.
You might call it a bug, but I'd rather speak of a limitation.
All programs that are written in languages such as C++ (internally
used in LilyPond) exhibit overflow issues when you feed them with
such huge integers.
So, unfortunately, I don't have a workaround to suggest other than
to use fractions with smaller denominators.
Jean
signature.asc
Description: This is a digitally signed message part
