[Top][All Lists]

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

Re: \tempo should accept floats

From: Urs Liska
Subject: Re: \tempo should accept floats
Date: Tue, 28 Mar 2017 19:16:50 +0200
User-agent: K-9 Mail for Android

Am 28. März 2017 18:41:55 MESZ schrieb David Kastrup <address@hidden>:
>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
>>>> provide.
>>>> \tempo 4 = 60.0
>>>> => error: syntax error, unexpected REAL
>>> So what do you expect to see here as the markup?  "♩ = 60.0" ?  And
>>> \tempo 4 = #190/7
>>> what do you expect to see here?  "♩ = 12.9"? "♩ = 12.86"?  "♩ =
>>> 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
>>> If LilyPond "should surely provide", the question is_what_  should
>>> 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.

So does this point to accepting a stribg argument without implications to thr 
actual tempo?
Of course this wouldn't be much morr than simplifying a markup entry.


>David Kastrup
>bug-lilypond mailing list

reply via email to

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