MIDI File Import Assistant

[RyanBram]

Hi, OpenMPT developers.
Many thanks for your efforts. .

I have tested several MIDI files and most of the results are sound almost identical with the originals. The only file that I found still little bit problematic is attached in this post for identification purpose. Even BeRoTracker result is sounds almost broken.

I also tried to convert the MPTM to MO3 and played it in XMPlay. The music tempo become slow. Then I tried to downgrade it to ImpulseTracker and the problem still occurs even in OpenMPT software. My current workaround is to lower the Ticks/Row by half and the tempo will back to normal. It seems even though MO3 Converter have supported MPTM format, but the Bass library itself still doesn't support some of MPTM features.

Best regards,
RyanBram

[Saga Musix]

It is correct that BASS does not support all MPTM features, and to spell this one once again, it is not my intention to provide an easy way to convert legacy MIDI files to legacy module formats, but to provide an easy way to import remix material into modern MPTM files. Thus, MIDI import always uses modern tempo mode and I will NOT change this. It would make the entire rewrite pointless.
I will look at the problematic file later.

[RyanBram]

No, I am not asking for bugfix here. I just want to report my test case here and my conclusion is BASS is not currently support all of MPTM features yet. Another users may found something like this and may also report similar case.
So I share my very simple workaround here in case some users with similar problem want to make sure their module file compatible with players other than OpenMPT.

About the previous attached file, thanks for looking into it.

[Brozilla]

Honestly the MIDI seems to have imported relatively fine but it just needs some manual work.

Note-ties do not appear to import properly with whole notes. They "note off" irregardless. Essentially you need to remove them if undesired.
Pitch bends may not always be accurate (to the midi) which may require extra work.
If your import does not have enough precision (Speed too high) then complex rhythms/async may be "misstepped" and vaguely sound off.

Unless I'm missing something the attached file imported "correctly" within the assumptions above. The first one might need more clarity but I do not believe note-ties are exactly broken but note duration cannot exceed 1 whole note, the duration of the whole note is affected by import speed.

[Saga Musix]

Just like Enumeratingw7 I cannot find anything that's specifically off here, so you will have to be more accurate with your report.

[Harbinger]

Must try. I'll report back — I have a slew of MIDI files that I'd love to update and convert from sequencer files to tracker files...

Downloaded r6887...

[Harbinger]

Very impressed with the new MIDI Importer and it was made so much easier than a third-party workaround.

Here's what i found with my testing:

1. When importing Tempo changes, everything was fine until the Tempo dropped below 32 BPM. The new MIDI importer faithfully assigned the Tempo commands to Txx to the given value, but of course T0x and T1x are Tempo Slides. I was definitely impressed that the new Importer assigned the Tempo changes to its own channel. If you're looking for an improvement, maybe the Importer could "smartly" assign the correct Tempo. I don't see how this can be done if the Txx cannot go below 32 BPM, so maybe it's time to consider a new "true tempo" command for MPTM. Maybe a txx volume command. Hmmm...

2. GREAT use of SCx to cut the notes and SDx to delay the notes. I didn't notice any errors in this department.

3. It was very helpful that the MIDI channels were imported to their own columns in the new file and named clearly so we could see how it was imported.

4. Still would have liked the chance to assign Instruments before the import. For example, when i imported my flute suites, i knew MIDI channel 1 was the piano and MIDI channel 2 was the flute. It can help the import if we can assign the MIDI instrument before it lays it down, so we don't have to go searching for it.

5. For some reason, the MIDI files i saved from my days of working with Pro-4 (from Master Tracks, but i believe GVox is now in control of that sequencing software), the instruments were not saved. I do know that some of my own MIDI files, when i bring them into another MIDI software like MuseScore, the track's instrument is apparently kept as a comment, probably because back then (we're talkin' early 90s), MIDI files only used external devices and it was up to the music producer to bring up the right program in his MIDI controller when he loaded the song in the software. In other words, if i open the MIDI score in Pro-4, it will create a track labeled "Piano" and another labeled "Flute." So obviously it's recorded in the original file. Perhaps if there is no MIDI Instrument found in the track, the MPT Importer can suggest one found in the comments of the track. When i downloaded a third-party MIDI file into MPT, the Instruments were assigned correctly and the Import played beautifully.

6. Impressed with the Pitch Bends (portamento). Those looked like they were accurately placed. (Damn, that's impressive!)

7. I noticed that some instruments (usually drums) had a mixture of MIDI instruments in a single channel, which i'm sure was in the original file. If i was to go in and edit it (which is really the only reason to import it into MPT, i'd want all instruments to be brought in to their own channel. Perhaps we can have that option available before importing.

I'm including a couple of examples to help with your testing and tweaking. I recommend importing them with amplified Velocities at least 200%.
The FC file is my own MIDI file created from a Mac using a sequencer software (Master Tracks Pro-4), with only two instruments, Piano and Flute. This file is from 1991 during my college days, and had been transferred from a Mac Double-Density floppy disk.
The second i believe came from an Alesis CD to demo the capabilities of this synth, using its GM specs, and the file properties shows it was from 1995. Importing this file does well, except for the pitch bends at the beginning, which i bet has to do with the Alesis' Pitch Range, which MPT wouldn't have any way of determining. But channels 38-41 hold the drum instruments.

Needless to say, the MIDI Import capabilities is LEAPS AND BOUNDS above what it was only a few months ago. I am very happy with the progress and except for unusual files, we can import any MIDI file with ease now.

[Saga Musix]

1. When importing Tempo changes, everything was fine until the Tempo dropped below 32 BPM.

Oops, will be fixed in the next commit by clamping the tempo to 32 BPM. There's no other sane way of doing this right now, and it is not my intention to work around it.

I'm including a couple of examples to help with your testing and tweaking. I recommend importing them with amplified Velocities at least 200%.

MIDI Velocity amplification is only for live MIDI recording and does not affect MIDI import.

So obviously it's recorded in the original file. Perhaps if there is no MIDI Instrument found in the track, the MPT Importer can suggest one found in the comments of the track.

I'm not going to apply any heuristics for instrument replacement. This is not where OpenMPT should (or could) do any guesswork, because there are a gazillion different ways of naming your MIDI tracks.

7. I noticed that some instruments (usually drums) had a mixture of MIDI instruments in a single channel, which i'm sure was in the original file. If i was to go in and edit it (which is really the only reason to import it into MPT, i'd want all instruments to be brought in to their own channel. Perhaps we can have that option available before importing.

There are simply not enough pattern channels to possibly allow each of the 128 possible MIDI programs to be used in each of the 16 MIDI channels and then create a separate pattern channel for them. I have based the whole importer on separating items by their MIDI channel, and doing it in any other way would require a complete require of channel allocation strategy. If this is a problem, it is once again a step that should be done in MIDI editing software (e.g. by moving instrument to different MIDI channels), as there is no "one size fits all" approach that OpenMPT could take.

which i bet has to do with the Alesis' Pitch Range, which MPT wouldn't have any way of determining.

There are a couple of pitch bend RPNs (yes, the same ones that you were asking about already a few years back) which OpenMPT also interprets during MIDI import - and as far as I can judge, it does so correctly. It's more like that the lack of imported lowpass filter commands produces a rather different sound in OpenMPT compared to a proper MIDI player at the start of the song. I won't implement support for CC74 (brightness, aka lowpass filter) though because that will just further complicate things (there are simply not enough command columns available).

[Saga Musix]

I've revised the pattern channel allocation strategy a bit to make files that use tons of simultaneous notes on the same MIDI channel look more tidy after import.
Note that this still won't fix your observation on drum channels - OpenMPT already tries to re-use the same channel for identical MIDI channels + note combinations, but MIDI events are handled first come, first serve - if you have e.g. a hi-hat line and suddenly there's a kick inbetween those hi-hats, then the kick will most likely move one of the hi-hat hits to the next channel, at least if it appears first in the MIDI file. There's no sane way this could be handled in a general manner in the import code (it would have to keep track of the past and future of the drum channel and at the same time also still work when running out of pattern channels), so if you really want to keep your drums tidy, you will have to resort to search&replace after import. Luckily that's just something you have to do once.

[Saga Musix]

More improvements in r6909: Fixed pitch bend import, sturdier RPN handling (the mechanism for selecting pitch bend depth) and support for sustain pedal.

[RyanBram]

More improvements in r6909: Fixed pitch bend import, sturdier RPN handling (the mechanism for selecting pitch bend depth) and support for sustain pedal.

Nice update. I tried r6911 and my previous attached MIDI sounds better now. Even most of my collection can be categorized as listenable. Sorry if the previous topic was an inaccurate report. I hope you still want to hear my report, because the attached MIDI in this topic is imported properly, but oddly all of the sample become mute. I cannot find out what the problem was.

Thank you for your attention.

[Saga Musix]

I cannot find out what the problem was.

Have a closer look at the global volume slider in the General Tab.

Will be fixed in r6913.

[Saga Musix]

More good news as of r6931:
- Support for XG drum kits on any channel.
- Finally found the reason for many SF2 soundfonts being hilariously detuned - the instrument region's finetune parameter was not imported at all.
- Even more (this time small) pitch bend fixes.

[RyanBram]

Great news.
I downloaded and tested the last version of OpenMPT. One thing that I hope can be improved are cymbal sound. It stop too fast instead of gradually fade out like in the original. (Maybe sound like ts.!, instead of tsssss......)  Strangely if I downgrade to IT and adjust the ticks/row, the cymbal sounds as expected.

Sorry if I cannot describe it well as my knowledge about musical terms are fairly limited. I attached a MIDI sample which often make use cymbal sound.

[Saga Musix]

See, I have been saying it a couple of times by now, but this is exactly not what MIDI import is about. I rewrote MIDI import so that people (like Harbinger, see above) can import their old projects or remix stems into OpenMPT and work with them. I did not rewrite this whole thing so that you can listen to your MIDI files without applying manual modifications.
OpenMPT simply applies a default envelope for drumkits (otherwise the looped cymbal sample would just play forever), and while this envelope may be rather short compared to what a different soundfont synthesizer would do, I'm not going to change it (if you wonder why, just try to imagine what an Open Hi-Hat would sound like with the envelope of a Crash Cymbal). You have full control over the envelope and can modify it to whatever you want it to sound like.

Strangely if I downgrade to IT and adjust the ticks/row, the cymbal sounds as expected.

This is merely an artefact of converting from modern tempo mode to classic tempo mode, because suddenly all envelopes will play twice as long (in case you use 6 ticks per row and a quantization level of 1/32nd notes). I hate it when people really just blindly import MIDI files and convert them to modules, but if you do so without understanding what exactly is happening when converting from modern to classic tempo mode, then at least please modify the import speed to 3 ticks per row so that the instrument envelopes are still played at the correct speed after conversion to IT - because otherwise, maybe your cymbal will sound nice now, but the envelopes of melodic instruments will be smearing all over the place. Or change the quantization level to 1/16th notes, but I doubt you'd want that with most MIDI files.