Re: Metronome marking with non-integer value

[Lib Lists]

> Interestingly, and this would have been the topic of my next message, the 
> resulting MIDI output is always correct whatever \tempo I put (it can be the 
> same \tempo for all staves). In the example below the top staff is always set 
> to 4 = 120 and the other staves correctly follow. I'm wondering if this is 
> because \scaleDurations overrides any \tempo indication, or because of 
> \cadenzaOn.
>
> In your code below, there are no custom MIDI tempo settings, since you did 
> not include any \set Score.tempoWholesPerMinute = ... command (\tempo adds 
> this along with a TempoChangeEvent, as Valentin explained).
>
> Even with \tempo, MIDI cannot have several tempi for several tracks I 
> believe. At any rate, LilyPond will just choose the last one seen, and 
> consistently apply it to all staves. Just try swapping the staves in
>
> \version "2.24.1"
>
> \score {
>   <<
>     \new Staff { \tempo 4 = 60 c'4 4 4 4 }
>     \new Staff { \tempo 4 = 120 c'4 4 4 4 }
>   >>
>   \midi { }
> }
>
> to hear the difference.

Hi Jean, thank you so much to you as well for the detailed explanation
and examples. I'm still getting the hang of how many aspects of
Lilypond works, and all of this is really useful.

>
> \scaleDurations does not override \tempo. But, it makes notes performed at a 
> different pace than what their written durations would normally make for. For 
> example, “\scaleDurations 2” will turn quarter notes into half notes for 
> MIDI, while preserving their appearance (filled note heads) in the printed 
> output.
>
> But it's not a problem, as it works as it should.
>
> In any case, here below an example that uses your 'Weird tempo' marking. Also 
> I added a rounding function found on Stack Overflow to avoid a visually too 
> long decimal. However, the resulting MIDI file doesn't show any visible 
> rounding issue.
>
> What about just making your own tempo marks as \markup ? I think that's more 
> future-proof than putting a non-integer into 'metronome-count while the 
> parser code would only let an integer pass through and downstream code may 
> thus legitimately (IMHO) assume it's integer.
>
> Something like the following should do it:

Fantastic, thank you so much for this!

Cheers,
Lib