Significant issue: Representation of tempo changes is incorrect in Midi file
brianavid opened this issue · comments
I must take issue with the reply to a separate post in the Euterpea1 project - https://github.com/Euterpea/Euterpea/issues/31 That reply said:
The effect of the Tempo modifier you have observed is not a bug; you're seeing the intended behavior. Tempo modifiers to allow for musical structures that do not adhere to the standard MIDI notion of beats and measures. The scaling of the offsets also allows for easier integration with MIDI streams. If you want write a MIDI file with a specific tempo, you can construct the music value as for 120bpm and then, within Euterpea 2, you can use a combination of the perform and toMidi functions to access the intermediate Midi type (which belongs to Codec.Midi) and alter timeDiv as desired.
My understanding is that is NOT how tempo should be handled in Midi files. I would expect any tempo modifier to correspond to a marked change in tempo within the music, to allow for faster and slower sections within a single piece of music without breaking the structure of the music in terms of beats and bars. Indeed, I would hope that later enhancements could allow for changing time signatures, although that would need the addition of a further Control constructor, such as “TimeSig Rational”.
This means that writing Midi files is different from playing to a Midi device in that tempo changes should NOT scale the durations, but simply insert the appropriate “Set Tempo” (FF 51 03 tt tt tt) meta event, with a restoring meta event at the end of the tempo-modified section. This is further divergence of the representation of Midi used for playing from that used for exporting.
Maybe this is pushing Euterpea into capabilities beyond its pedagogical role. But either we need to accept significant limitations in the music that it can handle, or we need to push for such fixes and enhancements. It seems so close!
The explanation from the other thread is still the same for Euterpea 2.
Maybe this is pushing Euterpea into capabilities beyond its pedagogical role. But either we need to accept significant limitations in the music that it can handle, or we need to push for such fixes and enhancements. It seems so close!
This is a case where trying to support too many specific features will ultimately detract from generality and simplicity in other parts of the system. Euterpea has had many altered versions made by people over time for specific purposes (for example, I wanted microtones at one point a long time ago, so I made an altered version specifically for that with additional constructors and such). That is the alternative I would recommend if you require these kinds of features.