Lmms: MIDI import misplaces notes

[softrabbit]

Reported on the forum: http://www.lmms.io/forum/viewtopic.php?f=7&t=5016

I produce my midi files with musescore 2.0.2 on Ubuntu 15.10 and save them with file>export in musescore.

What happens is that notes seem to be created at negative points in time when importing in LMMS, i.e. before the segment starts. The notes can be "resurrected" by opening the segment in the piano roll and moving the notes. Musescore always exports using running status, which some other software can't handle at all, so that's my prime suspect.

Using the midi2text and text2midi programs that come with the midifile library I converted the test file provided into one not using running status. The converted one imported correctly. As far as I can see the files are identical when it comes to note data, but there's some controller data in the original that's getting lost in the process, so I'm not quite 100% certain. But it's most likely the portsmf/allegro library that's somehow reporting wrong times to the next layer of the import code.

Sample files, the original with running status and the other without:
testfiles.zip

(:bulb: That midifile library looks like a good choice if MIDI import and export is to be rewritten at some point)

[midi-pascal]

@softrabbit I personally use a custom (i.e. enhanced) version of QMidi (https://github.com/waddlesplash/QMidi) project extensively in other personal projects. It does almost the same as midifile but is more Qt-oriented. It works like a charm with Qt apps.
Just to let you know it does exists :smile:

[softrabbit]

Did a little printf debugging, and the library reports the notes with correct time stamps, but not in chronological order. And the import code expects them to be; see smfMidiChannel::addNote() and think about what happens if n.pos < p->startPosition(). (Answer: nothing special, even if it should)

The events are ordered in the MIDI file, as every event has a delta time that's added to the time of the previous event in the track, so this is a slightly odd behavior on the part of the allegro library IMO. But the place to fix this is the import plugin, as it's entirely possible to have MIDI events assigned to the same channel in multiple tracks, which could trigger this same bug.

[ManfredHerr]

I also tried to import a MIDI file created by MuseScore 2.1 on Ubuntu 16.04 into a new project within LMMS. The first track with channel 1 (GM Clarinet) starts with 3 measures pause. The two tracks for piano should start first measure beat 2. But the first three measures are missing. Furthermore, both instruments have a shift in the measure, i.e they do not fit.

Arabesque valsante.mid.zip
Console messages:
MISSING GLOBAL THINGY
-1 9 300,000000 keysigi
MISSING GLOBAL THINGY
-1 9 300,000000 modea

[ManfredHerr]

After some investigation I noticed that the left hand is missing for the first measures only. The MIDI export of MuseScore uses for piano one channel but two tracks. LMMS tries to combine the two tracks into one segment for the channel. The right hand in the first track starts later than the left hand in the second track but determines the size of the segment. By combining the two tracks for the same channel into one LMMS can import the midi file. Imho, taking two tracks for one channel is a strange decision from MuseScore.

[musikBear]

@ManfredHerr i think its musescore that creates a special midi-file. When i import your midi-file, i get a bad result. But if i convert your file to midi0 in Anvil, i get a correct midi-import, however the TCO of the solo is placed out of clip-pos, eg between normal magnetics, at the 2½ bar pos, but that is also the case with your file! Except here it jumps to that in-between pos, as playback begins(?)
But a midi0 version (stdMIDI) imports like this:

So Musescore builds a somewhat strange midi-file, but that is not uncommon. There are almost as many proprietary midi-formats as there are midi-using proggies, that why converting to midi0 is available

__edit___
Might as well show both:

[PhysSong]

I found the real issue. When importing a type-1 MIDI file, events in a track are processed in the chronological order. If there are multiple tracks with the same channel, however, events for a channel may not be in order.
smfMidiChannel::addNote cuts pattern while assuming events are in the chronological order, but sometimes it's not true. In the example file, there are no notes in the first bar of the first track. It makes the pattern start at the second bar, and the first two notes from the second tracks are ignored because their start positions are before the beginning of the pattern.
https://github.com/LMMS/lmms/blob/3ada5b8a126b529c94cbe0c01b60a11ecb08dec8/plugins/MidiImport/MidiImport.cpp#L266-L273

[PhysSong]

I'm not sure how we should handle this. We may create a temporary pattern per channel and split them after importing all notes. Alternatively, we can disable the splitting feature.

[zonkmachine]

Fixed in https://github.com/LMMS/lmms/pull/5343