page200

Should we close this issue (because it was based on the assumption that tempo changes and pitch-bend changes that are stored inside some track don't affect other tracks in Format...

Many mido-based repos intend to have correct pitch info. But the mistake of using the default pitch-bend range of 2 semitones without taking pitch-bend range messages into account is not...

[`MidiFile.__iter__()`](https://github.com/mido/mido/blob/main/mido/midifiles/midifiles.py#L382-L400) iterates through the MIDI events and keeps track of info that is necessary for interpreting the meaning of later events. It keeps track of tempo changes and converts time...

> > We usually want to do that, while additionally observing pitch-bend range changes and computing correct pitch accordingly. > > I don't think this is mido's responsibility. This is...

Thank you for the nice discussions and commits! :) One comment: I'd favor renaming `resolution` to the units it is given in, such as `ticks_per_quarternote`.

In what way do you consider `ticks_per_quarternote` not descriptive enough, I mean, what variables except for resolution can be given in ticks per quarternotes? If there are such variables, let's...

Yes, this is about `Message` objects being mutable. Even if we make some of them immutable, the bug will still affect mutable ones. Even if `mido` didn't create any mutable...

Even if we make it impossible for users to pass mutable messages as inputs to `fix_end_of_track()` (which we shouldn't), users might still modify the code when experimenting with some algorithms...

(Note to myself: `merge_tracks()` has to use the safe mode because its output can be saved.)

> pitch-bend related changes have no business inside the midi file decoding logic. Why does [`MidiFile.__iter__()`](https://github.com/mido/mido/blob/main/mido/midifiles/midifiles.py#L382-L400) keep track of tempo changes and compute time in seconds accordingly, but shouldn't keep...