[Top][All Lists]

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

Re: \tempo should accept floats

From: David Kastrup
Subject: Re: \tempo should accept floats
Date: Tue, 28 Mar 2017 18:41:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Simon Albrecht <address@hidden> writes:

> Am 28.03.2017 um 17:47 schrieb David Kastrup:
>> Urs Liska<address@hidden>  writes:
>>> As discussion onhttps://github.com/wbsoft/python-ly/pull/90  shows
>>> floating point metronome numbers are surely something LilyPond should
>>> provide.
>>> \tempo 4 = 60.0
>>> => error: syntax error, unexpected REAL
>> So what do you expect to see here as the markup?  "♩ = 60.0" ?  And for
>> \tempo 4 = #190/7
>> what do you expect to see here?  "♩ = 12.9"? "♩ = 12.86"?  "♩ = 190/7"?
>> What for
>> \tempo 4 = #(/ 190.0 7) ?
>> I know how to format an integer.  But I have no way to guess what a
>> composer will want to see for some rational or floating-point number.
>> If LilyPond "should surely provide", the question is_what_  should it
>> provide?
> I don’t think there is any reason to allow Scheme expressions or
> usecase for doing so.

Midi can represent certain fractions exactly and others not.  Using
exact numbers will give the Midi representation the best shot at
figuring out the timing relation to use.  So there is a case for

> But in modern music it certainly occurs to have metronome marks with
> one or two (maybe more) digits behind the point. So I’d consider it
> sensible to additionally allow _only_ numbers in the form \tempo 4 =
> 123.45…  (there should be no point in restricting the number of
> ‘post-point digits’) (sorry, I’m not familiar with English
> mathematical terminology)

This is not how (binary) floating point works.

100.1 may well be 100.0999999999997 or similar.  There is absolutely no
issue with letting LilyPond _accept_ non-integers.  But I don't see a
plan how it could or should then go about formatting them.

David Kastrup

reply via email to

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