Replace GM.gls with GMGSx.sf2

[RyanBram]

Hi.
In the roadmap, OpenMPT has been planned to become cross platform software. As GM.dls is currently is Windows specific, why don't OpenMPT distribution bundled with GMGSx.sf2 as replacement for gm.dls.

GMGSx.sf2 is soundfont created by Kenneth Rundt author of Synthfont. It is public domain licensed and has similar sound output as gm.dls or Roland gs.sf2 . It can be obtained in Synthfont 2 installation folder, or you may visit this Dropbox link: https://www.dropbox.com/s/qxdvoxxcexsvn43/GMGSx.sf2?dl=0

[Saga Musix]

OpenMPT does not distribute GM.DLS, so why (how) should be replace it with anything else?
Since OpenMPT is not centered around General MIDI, so I am not going to package a General MIDI soundfont with it just because some people think that OpenMPT would be a good tool to listen to MIDI  files or even convert MIDI files to modules.
When, at some point in the future, OpenMPT becomes platform-independent, we can simply search for existing soundfonts that come with other MIDI players on those platforms, just like we do it with GM.DLS.

[RyanBram]

OpenMPT does not distribute GM.DLS, so why (how) should be replace it with anything else?

OpenMPT also does not distributed with MFC because it is part of Windows, but to make it cross platform I read somewhere you will replace it with another toolkit. AFAIK Qt is the candidate for MFC replacement. So replacing GM.dls with GMGSx.sf2 is something like replacing MFC with Qt.

Since OpenMPT is not centered around General MIDI, so I am not going to package a General MIDI soundfont with it just because some people think that OpenMPT would be a good tool to listen to MIDI  files or even convert MIDI files to modules.

I don't think VST also come from tracker world nor supported in any module formats other than MPTM or XRNS. It seems the reason for VST and DLS/SF2 support in OpenMPT is because of their usefulness for easing tracker creation or music in general no matter where the tools originally come from. Format like .mid and .it are just specification, Sekaiju and OpenMPT are some of the tools, so no matter where the tool come from, as long as it can create valid format then it can be used. Because I heard there are user that use OpenMPT for composing .mid and there are users that use MIDI sequencer to create module format with help from conversion tools like MID2XM or Renoise. And it is not uncommon to see user that use Powerpoint for designing digital graphic even though it is not the main purpose of Powerpoint. If it works for the users then nothing can stop them.

When, at some point in the future, OpenMPT becomes platform-independent, we can simply search for existing soundfonts that come with other MIDI players on those platforms, just like we do it with GM.DLS.

For consistent user experience in each platform, OpenMPT cannot depends on platform specific solutions which may even not exist such as in Linux distro which many of them didn't packed with default soundfont. I don't think the cross platform version of OpenMPT will use MFC for Windows, Cocoa for OS X, GTK+ for GNOME, and Qt for KDE instead of using just Qt for all of the supported platform.

After all, just take my comment a grain of salt. Replacing gm.dls with GMGSx.sf2 or other soundfont for my personal use is easy for me, but asking the inclusion into OpenMPT distribution is another matter. It just suggestion from me as the user to the developer to make OpenMPT better in my point of view. If it match with goal of OpenMPT, just take it, but if it against goal of OpenMPT, just ignore it.

Thanks.

[LPChip]

So replacing GM.dls with GMGSx.sf2 is something like replacing MFC with Qt.

Seriously?

Please explain me, how can we replace something if we don't even ship it? Lets just say we add GMGSx.sf2 to OpenMPT, then you would have both GM.dls and GMGSx.sf2, because GM.dls ships with windows, not with OpenMPT.

But as SagaMusix has pointed out before, that we support the GM.dls is a bonus. OpenMPT is not a midi editor, and by actively shipping GMGSx.sf2 we make it seem like it is.

OpenMPT is not suitable for creating midi files. It can do so but only barely. It is better suited in case you want to examin a midi file, but should definitely not be used as an actual editor. OpenMPT simply makes way too many mistakes when importing midi files due to how a midi file is so much different compared to a module. For example, modules are very structured and precise when it comes to note placements. Midi's on the other hand can have a .2 second delay on the note and still be valid, whereas with OpenMPT it has to guess where the note comes, it will then remove that delay, and suddenly its not the same song anymore.

Songs that were composed with the quantisize function enabled will not have this problem, but there are many other reasons why importing goes wrong or makes a very hard to edit song.

Me as user of OpenMPT, I don't use the gm.dls at all. So if OpenMPT suddenly starts to include a big sf2 file, that means I'm downloading more that I'm not using. Besides there are plenty of sf2 files out there. I have a huge library of sf2 files on my harddrive that I used in the past to play midi files using my creative x-fi soundcard. One of my better libraries is over 300 mb big. If I want to substitute the gm.dls file, I'll use one of those instead anyway.

[StarWolf3000]

Besides, going platform-independent in the future would also mean to rid of the currently used plugin architecture, as the VST system is only available for Windows hosts primary, and is not guaranteed to work with Wine on several Linux systems for example. Most Linux systems require LADSPA plugins instead, and on macos you have the Audio Unit plugin interface.

[manx]

OpenMPT also does not distributed with MFC because it is part of Windows, but to make it cross platform I read somewhere you will replace it with another toolkit. AFAIK Qt is the candidate for MFC replacement.

OpenMPT (and i think also original ModPlug Tracker) always shipped MFC itself (statically linked).

So replacing GM.dls with GMGSx.sf2 is something like replacing MFC with Qt.

No, reading samples from GM.dls is an optional features. A GUI toolkit is not an optional component of a GUI program.
We do not ship GM.dls or any other samples, and will certainly not start doing that. There are gazillions of free sample libraries around with compatible licenses. Where would we stop shipping samples?

For consistent user experience in each platform, OpenMPT cannot depends on platform specific solutions

OpenMPT does not depend on GM.dls. It is able to use it if available.
OpenMTP uses various platform-specific features already, without impacting consistency in an major way:

• compressed sample decoding via MediaFoundation (only available on Windows 7 or later, not available on Wine)
• various really platform-specific sound device drivers (WASAPI, ASIO, WDMKS, WaveRT, PulseAudio, ALSA)
• probably more stuff that I cannot remember right now

I don't think the cross platform version of OpenMPT will use MFC for Windows, Cocoa for OS X, GTK+ for GNOME, and Qt for KDE instead of using just Qt for all of the supported platform.

I'd imagine it would use MFC on Windows and QT on everything else as well as Windows for quite some time in parallel, maybe even forever.

Besides, going platform-independent in the future would also mean to rid of the currently used plugin architecture, as the VST system is only available for Windows hosts primary, and is not guaranteed to work with Wine on several Linux systems for example.

There is no technical obstacle to supporting Windows VST plugins in a potential future native Linux OpenMPT version. This can either be implemented via a custom bridge based on Wine, or using some existing Linux VST bridge (which I think thereof do exist multiple ones).

OpenMPT is already kind of cross-platform by explicitly supporting Wine.

Most Linux systems require LADSPA plugins instead, and on macos you have the Audio Unit plugin interface.

OpenMPT 1.27 can even use some native Linux sound drivers. In theory, OpenMPT running on Wine on Linux could also use Linux-native plugins This is just a matter of implementing corresponding bridge functionality.

In any case, cross-platform OpenMPT would certainly not change VST support on Windows. Other plugin architectures could additionally be integrated just as well as VST is.


In any case, the ability to optionally use some system-provided soundfont is by very very far the least of the problems to be solved on the way to any kind of real cross-platform support. Frankly it's very close to irrelevant, given the amount of work in total.

[Saga Musix]

In addition to what manx said:

I don't think VST also come from tracker world nor supported in any module formats other than MPTM or XRNS.

Supporting VST is a conscious decision and one of OpenMPT's most important features. Half-working soundfont import, on the other hand, is not, even if you personally think it's the most important feature for yourself.

Besides, going platform-independent in the future would also mean to rid of the currently used plugin architecture, as the VST system is only available for Windows hosts primary

VST is only an API and VST plugins also exist on Linux and OSX - there is no "requirement" for LADSPA for a linux audio host, it would just be a more widely supported plugin format. And OpenMPT itself already supports more than one plugin type (VST and DMO), so there is no reason why it should not support LADSPA in a future version.
In fact, many VST plugins are available as an OSX and Windows build these days, and especially open-source ones are also available on Linux. VST plugins (as a concept) do in no way depend on Wine - only Windows VST plugins do.

All of these arguments are completely besides the point.