On Thu, 19 Oct 2023, 03:49 Jean Abou Samra, <j...@abou-samra.fr> wrote:
> 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
>
Would a function that turns a fraction into whatever number/1000000 work?
\scaleDurations \ratio 1/29 % or 1 29
Cheers,
Vaughan
