ModPlug Central

Note: This tool is no longer required as of OpenMPT 1.27.

I made a tool that helps you import MIDI files so that notes align to rows like you want.

When opening a MIDI file, OpenMPT focuses on fitting an even number of MIDI file ticks into one module tick based on their durations in microseconds. If you want to align MIDI file notes to module rows, you have carefully plan the size of the MIDI file ticks in microseconds yourself.

The OpenMPT MIDI File Import Assistant is focused on letting you choose what MIDI file note value the module row represents. When you set the MIDI file tempo and OpenMPT MIDI file import Speed to the indicated values, the imported MIDI file notes will align to rows as you specified. The Assistant also helps you set the beat, measure, and pattern sizes to useful values, and helps you reset the module tempo to play notes at the same speed as the original MIDI file.

The OpenMPT MIDI File Import Assistant has the following requirements:

• The MIDI file uses PPQN resolution, and you can find out the exact resolution value it uses.
• The MIDI file notes are aligned to note values (quarter notes, eighth notes, and so on).
• The MIDI file uses exactly one Tempo event at the very beginning, and you are able to change it to a different value to help the import process work correctly.
• The Assistant is an HTML file that runs in your web browser.

Update Version 1.1, 2012-04-29: Added sections and headings to clarify which values are from the MIDI file and which values you choose. Added Next/Back buttons to show the calculated steps on a separate "page".

Looks interesting for sure! Now if OpenMPT just had better MIDI support... :D

Okay, i gave it a good try, using Anvil as my MIDI import/export application...

I've never used a web-based app before so this was brand new to me, and i wasn't sure what it would do. From your description i thought it would prepare a MIDI track for importation by MPT, but not so -- i hafta do all the work! >:(   Oh, well... :P

Once i figured where to find the info the little program needed, i followed its instructions and altered the MIDI, saved it*, and then imported it into MPT, which, for those who don't know, will transmogrify the MIDI data (not the MIDI file itself, so that's safe) into an IT-compat track. *Word to the wise: once you make your changes suggested by this MIDI Helper to the MIDI file you want to bring over to MPT, be sure to save it as another file, as you will often hafta change the tempo setting for import, meaning the MIDI file will have a new tempo.

I tried a couple of my own MIDI files assembled on a Mac with Master Tracks Pro-4, as well as third party .mid files that came from various sources. The tracks composed on Pro-4 did not retain MIDI instruments (or else Anvil couldn't read them), so i often had to fix that.

But anywho, following the instructions DID lead to a better import into MPT. There should be clearer instructions as to the "Row units" as in, "Which note length should one row in MPT represent? Enter its Units amount." or some such. But i did figure it out eventually (i'll be the first to admit i overthink things) and when i followed the instructions it seemed to always work. It is after all only a helper, and what it's helping you do is modify the tempo of the original track, then fixing MPT's MIDI Import options so it'll delineate it properly into your patterns.

So all in all, it does what it's supposed to do, and makes MIDI import 100 times easier, as it does all the calculations for you. But it is a bit clunky and with this wonderful technology, it should somehow be incorporated into MPT's GUI.

Excellent work, Bavi! ;D  We thank you!! 8)

I started this project because I was frustrated that when OpenMPT opened a MIDI file, the notes didn't align to rows in any predictable way. When I searched online I couldn't find any explanation of how OpenMPT aligns MIDI file notes to rows, and only found suggestions to play around with the MIDI file import settings.

So I dug into the OpenMPT code to figure out how the the MIDI file import converts MIDI file durations into module rows. Once I understood how it works, I determined you could select a specific MIDI file tempo and import Speed setting to control what note value is assigned to a row. So I started to make an HTML file JavaScript calculator to help you choose the correct values. But I kept thinking of other things you would want to set: You want to make sure the pattern size is useful, and the measure size, and the beat size. And since you usually have to change the MIDI file tempo as part of this process, wouldn't it be helpful if you could change the module tempo back to match the original MIDI file tempo? So I added those calculations too, but this made it a bit more complicated to use. I think I'll expand the readme file with more instructions this weekend.


If OpenMPT's MIDI file import is ever eventually revised, perhaps the concept of fitting MIDI file ticks into module ticks could be abandoned. (I don't understand if that is ever useful?) In the MIDI file import settings, perhaps the Speed setting could be removed and replaced with a setting for how many MIDI file ticks to put into a row, or how many rows to put into a MIDI file quarter note.


P.S. For editing MIDI files, have you heard of Sekaiju (http://openmidiproject.sourceforge.jp/Sekaiju_en.html)? It has a few drawbacks (difficult to enter time signature, doesn't play notes well if you switch to another application, limited notation view), but it is better looking and more organized than Anvil Studio. (If you download Sekaiju, be sure to change the Language setting in the ini file to English.)

P.P.S. For MIDI file notation view, I like Notation Player (http://notation.com/DownloadNotationPlayer.htm). (The download link is at the bottom of the comparison table.)

The MIDI loader will eventually be rewritten - when that is going to be, I have no idea, though. I have the MIDI import code of BeRoTracker lying around here (which allegedly works better than OpenMPT's), but it's in Delphi, so I'll have a *very* hard time translating this (if someone's both fluent with Delphi and C++... hint hint).

Quote from: Harbinger on April 05, 2012, 13:56:42There should be clearer instructions as to the "Row units" as in, "Which note length should one row in MPT represent? Enter its Units amount." or some such.

I reorganized the input boxes into sections with headings to make it more clear which values are from the MIDI file and which values you choose. You can download the updated attachment from the first post.

I just looked at Sekaiju's page now and saw that the author have also written some libraries for midi, these are written in c++, maybe it is usable for modplug tracker?

http://openmidiproject.sourceforge.jp/index_en.html

Quote from: Bavi_H on April 29, 2012, 20:06:38
I reorganized the input boxes into sections with headings to make it more clear which values are from the MIDI file and which values you choose. You can download the updated attachment from the first post.

That looks a lot more intuitive and easy to use indeed.

Quote from: Rakib on April 29, 2012, 20:16:56
I just looked at Sekaiju's page now and saw that the author have also written some libraries for midi, these are written in c++, maybe it is usable for modplug tracker?

I don't really see how a few classes for processing MIDI events should help with MIDI file format support. It's not like reading the MIDI events was the tricky part of reading a MIDI file.

Starting from OpenMPT 1.27, this workaround will finally no longer be required.
For testing of the new MIDI import, you can download r6841 from https://buildbot.openmpt.org/builds/ (within the next few hours). Be sure to check out the new quantization options in the MIDI settings.

What has changed:
- Accurate timing by translating PPQN to module tempo.
- Support for variable tempo.
- Pitch bends are still a bit wonky but will hopefully be fixed later.
- MIDI files are imported as MPTMs to take advantage of modern tempo mode and Delay-Cut notes.
- Due to modern tempo mode being used, any other ticks/row setting than 6 will currently sound a bit weird because soundfont envelope lengths are not adjusted accordingly. This will probably be fixed later.
- OpenMPT tries to allocate up to seven channels for each MIDI channel. Sometimes this is obviously not enough, so notes may overflow into neighbouring channels. But it's still more tidy than before, I'd say. Unused channels are cleaned up after the conversion.
- Many other changes, essentially the whole loader has been rewritten and pretty much no part of the old loader has been kept.

The MIDI import is FAR better with this test build.
I loaded my old MIDI files from PianoRollComposer, and it imported them spot on.
Only thing bothering me are the missplaced note offs.

What do you mean by "misplaced"? Note-Offs are just as precisely placed as Note-Ons. If you didn't place them carefully, of course they will just show up somewhere in the pattern, which is of course more obvious with OpenMPT's rather crude default MIDI bank but less obvious with a proper MIDI synthesizer.

QuoteWhat do you mean by "misplaced"?

It looks and sounds to me, as if the instruments get cut off to soon.

QuoteNote-Offs are just as precisely placed as Note-Ons. If you didn't place them carefully, of course they will just show up somewhere in the pattern, which is of course more obvious with OpenMPT's rather crude default MIDI bank but less obvious with a proper MIDI synthesizer.

Might be the case.

QuoteIt looks and sounds to me, as if the instruments gets cut off to soon.

It is the case then.
Once again I'd like to highlight here that MIDI import is not thought of as a way to listen to MIDI files. It's just thought as a first step for porting MIDI-based projects (or remix stems) to OpenMPT for further editing. MIDI import does not generate a listenable, final product.

Good work. I used MIDI->Renoise->xrns2xm->OpenMPT before. :P

r6847 contains a bunch of more fixes, in particular pitch bends are more accurate now. They still don't sound perfect, which again is not the goal of the importer.

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

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

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.

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.

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.

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

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...

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

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. 8)

Quote1. 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.

QuoteI'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.

QuoteSo 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.

Quote7. 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.

Quotewhich 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 (https://forum.openmpt.org/index.php?topic=4764.msg38954#msg38954)) 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).

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. ;)

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

Quote from: Saga Musix on August 18, 2016, 00:24:58
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.

QuoteI 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.

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.

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.

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.

QuoteStrangely 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.

Quote from: RyanBram on August 20, 2016, 15:18:24
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.

Saga Musix kinda already mentioned this but you could just change the instrument envelope on the offending cymbal. The MS Roland GM library is pretty lame if you ask me so not sure why it's a problem.

Quote from: RyanBram
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.

I don't think we use "musical terms" here that much but it's important to know the program isn't magic. Some teachers/professors like to say "what you put in is what you get out," and the like. Apparently there are bugs/fixes going on but I'm still on "revision 6609" and have no notable issues with the midi import.

QuoteThe MS Roland GM library is pretty lame if you ask me so not sure why it's a problem.

Indeed, and there are so many better soundfonts that can easily replace it (while testing, I have been particularly fond of "Yamaha XG Sound Set.sf2", which makes the MIDI files almost sound like a mid-90s module :D).

QuoteI'm still on "revision 6609" and have no notable issues with the midi import.

Then you should get a recent test build from https://buildbot.openmpt.org/builds/ and be amazed how much more accurate MIDI import is now. :P In particular, the most important feature for anyone wanting to make serious use of this feature is the proper alignment of MIDI beats to the pattern grid.

Hi Enumeratingw7,
Technically the MIDI Importer is much improved and tidier than in the previous version of OpenMPT. But in my opinion sometimes some instrument doesn't sound good compared to the original. Even replacing default GM.dls with another .sf2 still doesn't automatically solve cymbal problem. Thanks to you and Saga help I can begin to figure out the problem although I have to admit I still far for knowledge about using OpenMPT due to my lack of musical terms knowledge to give better understand about what have been writen in the manual. I know some musical terms in my language Bahasa Indonesia but it is often confusing when translated to English even by using Google Translate because too many difference when learning music in my own language and understand it in English.

For Saga,
I am aware about your warn about your intention in improving MIDI importer. But by looking your effort in creating MIDI importer from scratch and how often your commit in SVN (this is the first time I watch sorce code progress of OSS project daily) for MIDI importer improvement, then I talk myself "maybe" I still have chance for asking Saga to do small fix like cymbal sound improvement, at least before next OpenMPT stable release which mean you will focus on another improvement. Because if MIDI synthesizer can handle hi hat and cymbal sound well, there must be a way to make it works in OpenMPT which once again I am aware it is not your intention in the first place.
I use technology mainly to make more accessible for me to reach something that I don't have many knowledge about it. That's why I prefer to use simple MIDI editor like Sekaiju over full featured DAW like LMMS, simple game creator like Construct 2 over advanced game creator like Unity, and OpenMPT instead of Renoise. Because OpenMPT is a software that make it easier for me to access tracker music creation (something that increasingly rare today) than Renoise thanks to the much improved MIDI importer.

Finaly, I want to apologize if asking you too much. I understand that it is my own job to solve my own problem. I really appreciate to what you and Manx done so far. Many, many thanks to both of you and OpenMPT contributors for all of your efforts.

Best regards,
RyanBram

Quote from: RyanBram on August 21, 2016, 01:11:48But in my opinion sometimes some instrument doesn't sound good compared to the original.

You need to understand that instruments have absolutely nothing to do with MIDI import, and there is no easy way to fix it. OpenMPT is not a soundfont player. End of discussion.

If you can just put the notes on the right row, i'll figure out the rest! :P I'm just happy those old files aren't lost in their binary purgatory, thanks to your efforts...

Thanks for whatever extra you can do!! 8)

QuoteIf you can just put the notes on the right row, i'll figure out the rest! :P I'm just happy those old files aren't lost in their binary purgatory, thanks to your efforts...

Same here.

Saga Musix, manx, and whoever else helped in the development of OpenMPT and the late and improved MIDI imported,  thank you.

Quote from: RyanBram on August 21, 2016, 01:11:48
I am aware about your warn about your intention in improving MIDI importer. But by looking your effort in creating MIDI importer from scratch and how often your commit in SVN (this is the first time I watch sorce code progress of OSS project daily) for MIDI importer improvement, then I talk myself "maybe" I still have chance for asking Saga to do small fix like cymbal sound improvement, at least before next OpenMPT stable release which mean you will focus on another improvement. Because if MIDI synthesizer can handle hi hat and cymbal sound well, there must be a way to make it works in OpenMPT which once again I am aware it is not your intention in the first place.
I use technology mainly to make more accessible for me to reach something that I don't have many knowledge about it. That's why I prefer to use simple MIDI editor like Sekaiju over full featured DAW like LMMS, simple game creator like Construct 2 over advanced game creator like Unity, and OpenMPT instead of Renoise. Because OpenMPT is a software that make it easier for me to access tracker music creation (something that increasingly rare today) than Renoise thanks to the much improved MIDI importer.

If you have some funds you might want to consider hiring a musician or audio programmer. Otherwise just play with the program some more. Look at the tracker files in the free music downloads section. Not only does it [OpenMPT] have an excellent MIDI importer but the program is capable of so much more. I've barely scratched the surface!

A couple more recent (and not-so-recent, I just forgot to mention them) improvements:
- Support for channel transpose (RPN 2) and master transpose (XG SysEx) - note that both will only affect notes triggered after that command
- Support for RPN increment / decrement (CC 96/97)
- Support for type 2 MIDIs (does anyone have any of those?)
- In addition to embedded soundfonts in RMI files, OpenMPT now also searches for soundfonts with the same name as the MIDI file in the current directory - so if you have e.g. foo.mid and foo.sf2 in the same folder, foo.sf2 will first be tried when loading instruments for foo.mid, and if an instrument is missing from there, OpenMPT's MIDI Library is tried instead.

Oh, and the SF2 coarse tune property was previously ignored, which could also lead to some instruments not being tuned correctly. This is now fixed.

good work. OpenMPT stayed so much time with buggy sf2 imports it was almost ridiculous

Everyone was welcome to fix it. :P

Quote from: Saga Musix on September 18, 2016, 11:41:20
Everyone was welcome to fix it. :P

Out of curiosity, is it possible to use code from this project https://github.com/schellingb/TinySoundFont to improve OpenMPT SF2 support.

No, because OpenMPT is not a soundfont player at heart. It does fundamentally different things (stuffing SF2 data into its own limited module-centric world) when importing a soundfont file compared to any regular soundfont player.