Hi David, in case you or someone else is going to refactor the time signature code, please also consider the discussion that we already had about this topic in May 2002. See here:
https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00088.html The suggested syntax as of then would have known the difference between 6/8 (=3+3 8th) versus 3/4 (=2+2+2 8th) thanks to the prolatio property. Best wishes, Jürgen On Sun, Jun 6, 2021 at 11:32 PM David Kastrup <d...@gnu.org> wrote: Ok, I have a problem here. Our MIDI time signature codes are wrong. The problem that I have in fixing this is that part of the information in a MIDI time signature is actually (typically) specified in \tempo instead. Here is how this works: a MIDI time signature contains numerator (fine), denominator (coded like our duration-log), midi clocks (of which there are 24 per quarter note) per beat, and 8 (32nd notes per quarter which we keep constant). The midi clocks per beat is basically what we could get from the closest \tempo ... = duration specification, by taking duration in terms of whole notes and dividing by 96. This value is hardcoded as 18, corresponding to 8. (3 16th notes). That does not make a whole lot of sense. The sane way would be to take the information from the currently valid \tempo (if specified) or otherwise apply a time signature specific default (for 6/8, we don't want 6 beats per measure but 2, for example). I'd argue that if we have \tempo 60 \time 6/8 then we should likely interpret this (regarding the MIDI playing speed) as \tempo 60 = 4. \time 6/8 which would produce a different MIDI file rendition speed than what we have now, because that would be the most reasonable interpretation for the _visual_ rendition of \tempo 60 \time 6/8 In other words: looks like a long-standing mess in some need of cleaning up. Another possible information source may be the beat grouping information for a time signature (used for beaming patterns). That one will turn out to be a puzzler for things like \time 3,2 5/4 However, we could try to pick the gcd from the beat groupings and use that as a multiplier for the beat length (typically the time signature denominator). That would be tempo-independent and probably correct more often than not. And tempo-independent would leave us with a quite smaller head-ache. -- David Kastrup https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00088.html
