[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-integer tempo marking
From: |
David Kastrup |
Subject: |
Re: Non-integer tempo marking |
Date: |
Sat, 23 Feb 2019 13:04:01 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Aaron Hill <address@hidden> writes:
> On 2019-02-22 11:29 pm, Martin Tarenskeen wrote:
>> I tried to create it as a \markup. For MIDI output this doesn't work
>> though. You could add \midi { \tempo 8 = 145 } for that.
>>
>> %%%%%%%%%%
>>
>> \score {
>> {
>> \tempo \markup {
>> \concat {
>> \smaller \general-align #Y #DOWN
>> \note #"4" #1 " = 72.5"
>> }
>> }
>> c'
>> }
>>
>> \layout {}
>> \midi { \tempo 8=145 }
>>
>> %%%%%%%%%%
>
> Should \tempo be used within a \midi block? According to a rule in
> convertrules.py, it was deprecated in favor of directly setting
> tempoWholesPerMinute, which supports being set to any rational number:
>
> %%%%
> \midi { \context { \Score
> tempoWholesPerMinute = #(ly:make-moment 987 29) %% ~136.138 BPM
> } }
> %%%%
It was not "deprecated" as much as illegal syntax.
> Mind you, that rule was back in 2.9.16.
And mind you, a rule reversing that rule was placed in 2.15.32 as a
followup to
commit e995ed461610c2bb9c9cd43eaa715905b8525b95
Author: David Kastrup <address@hidden>
Date: Sun Feb 26 19:16:00 2012 +0100
Allow music with layout instructions in output definitions.
This allows things like
\layout { \accidentalStyle modern }
or
\midi { \tempo 4 = 80 }
to work as intended.
> And it doesn't sound like anything was actually deprecated if \tempo
> still works in \midi.
It wasn't deprecated, it was invalid until 2.15.32.
> Regardless, it should be noted that LilyPond internally only supports
> specifying an integral number of quarter notes per minute. This comes
> from Tempo_performer::process_music casting the rational
> tempoWholesPerMinute to an integer after multiplying by four, since
> Audio_tempo::per_minute_4 is an integral type.
>
> If we consider the crazy value in my example above, LilyPond would end
> up storing this as only 136 BPM before converting it to the value
> stored in the MIDI file.
The BPM logic warrants eventual revision since it hardcodes 384 MIDI
clock ticks per quarter note in
lily/audio-item.cc: return int (moment_to_real (m) * 384 * 4);
lily/midi-walker.cc: Real (384 * 4)) + now_ticks;
lily/performance.cc: midi_stream.write (Midi_header (1, tracks_, 384));
and probably other locations.
> The MIDI specification allows pretty fine granularity for tempo,
> letting you specify the number of microseconds per quarter note. For
> 136.138 BPM, that works out to 440,729 microseconds per quarter note
> whereas an exact 136 BPM is 441,176 microseconds per quarter note--a
> difference of about 447 microseconds per quarter note. After 2,237
> quarter notes--roughly 16.45 minutes of music--there would be a drift
> of one second.
>
> tl;dr: \tempo 8=145 will unfortunately not result in \tempo 4=72.5.
> Depending on rounding, it would end up as either 72 or 73.
--
David Kastrup