Change parser to mido

[craffel]

cc @douglaseck, @cghawthorne

The current backend, python-midi, does not appear very actively maintained. The last release was over 3 years ago, despite 63 commits since then. The current entry in PyPI is not installable (nothing has been uploaded). There is another entry in PyPI, but it states that it is v0.2.4, which does not appear to be an official release, and either way is almost 2 years out of date. The python-midi PyPI package also is not maintained by the actual package owner. pretty_midi depends on commits to python-midi which have happened since v0.2.3, so pretty_midi is effectively not PIP-installable (not to mention the questionable nature of depending on a PyPI package which is not maintained by the package owner). There doesn't seem to be any activity to solve these issues.

Alternatively, mido also provides a pure-Python MIDI parser. It was developed after python-midi was created, so using mido from the getgo was not an option. It is much more actively maintained, with frequent releases, quick merging of PRs, etc. Assuming there are no package-specific issues, we should switch to using mido.

[carlthome]

When mido is being used instead, could pretty-midi also expose the MIDI type? It would be very useful for a number of cases, like when synthesizing Lakh with MrsWatson for example. 😄

[craffel]

Do you mean the MIDI file type (type 0, type 1)? In what circumstance is this important?

[carlthome]

Yes. For example, MrsWatson only reads type 0 at the moment, and will halt if a type 1 is input.

[craffel]

Oh, do you mean when writing, being able to specify whether you want to output a type 0 vs type 1 MIDI? Hm, this is out of the scope of this issue for sure (it could be implemented regardless of the backend), but we could potentially consider it. I didn't realize there was any modern software that didn't support type 0. That's sort of a bummer.

[craffel]

I have this mostly implemented, but I have discovered two MIDI files which are parsed differently by mido and midi, e.g.:

>>> for t in mido.MidiFile('Musica musica.mid').tracks:
...     print len(t)
...
4
1
1
7
342
1523
484
1660
682
3550
1094
1466
54

>>> for t in midi.read_midifile('Musica musica.mid'):
...     print len(t)
...
6
7
342
1523
484
1660
682
3550
1094
1466
54
720
56

Not sure which one is correct, or where this difference comes from. I can investigate, but it will be slower going than work on pretty_midi. @douglaseck @cghawthorne if either of you would like to investigate, I can send you the problem MIDIs.

[douglaseck]

Please send them!

On Sep 29, 2016 10:41 PM, "Colin Raffel" notifications@github.com wrote:

I have this mostly implemented, but I have discovered two MIDI files which
are parsed differently by mido and midi, e.g.:

for t in mido.MidiFile('Musica musica.mid').tracks:... print len(t)...41173421523484166068235501094146654
for t in midi.read_midifile('Musica musica.mid'):... print len(t)...67342152348416606823550109414665472056

Not sure which one is correct, or where this difference comes from. I can
investigate, but it will be slower going than work on pretty_midi.
@douglaseck https://github.com/douglaseck @cghawthorne
https://github.com/cghawthorne if either of you would like to
investigate, I can send you the problem MIDIs.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#99 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APQ6QgRwOdHCT3B5BWHb8VJh55_5Npzfks5qvKEIgaJpZM4KIJAw
.

[craffel]

Posted an issue on the mido repository in case they have any ideas. mido/mido#62