Misc. MIDI format support
Brought to you by:
dynamite
Menu
▾
▴
#30 Misc. MIDI format support
Although AdPlug already supports MIDI format, there are some MIDI variants yet to be supported by AdPlug, including GMD (General MIDI?), HMI (Human Machine Interface MIDI), HMP (Human Machine Interface MIDI?), HMZ (), MIZ (), MSS (Miles Sound System XMI + MLS/DLS sound bank), RMI(RIFF-MIDI), XMI (Extended MIDI).
XMI is supported by Miles Design Audio Interface Library, which is used in games such as Caesar II. The file structure looks like the IFF/LBM file format, but contains audio data. The above mentioned formats are supported by Wimamp MIDI plugin.
It seems a bit redundant to have these formats implemented in a MIDI plugin and then all over again in AdPlug, when they're not even meant to be Adlib formats. Perhaps, if the intention is just to listen to these formats though an OPL synth, it would be better to somehow add support for AdPlug to the existing MIDI plugin?
It would be redundant if there were other MIDI plugins that use (emulated) FM samples, and have licences compatible with AdPlug, but that does not seem to be the case. If the intention is just to listen to music though an OPL synth, it may be better to just remove the emulated hardware limitations of 18 channels and 4-op effects only at selected channels as well, but the whole point of the AdPlug OPL emulation is to simulate the effects of playing music through the hardware. In the case of Human Machine Interface and Miles Sound System MIDI, that also imply emulating the behaviours of these APIs processing MIDI within the limits of audio hardware. If future development direction of AdPlug is to turn it into a generic OPL/FM synthesizing engine (which I also support), then it will make sense to add support for AdPlug to the existing MIDI plugin, assuming a MIDI plugin with compatible licence is available.
In any case, reimplementing MIDI form in AdPlug when there are other MIDI plugins is not redundant, because there are prior applications that play MIDI music through OPL hardware, which sound different from MIDI through digitized samples. MIDI would also sound different from AdPlug vs generic MIDI player with sample synthesizer engine because the existing MIDI files, particularly those included with games, may be optimized with the limitations of specific audio hardware, including OPL sound cards. Even if AdPlug starts to implement OPL4 emulation (which includes wavetable mixing), there can still be songs designed to exploit the limits of hardware (eg: Moonblaster).
Reimplementing these formats in AdPlug is still redundant, because there are really three parts to the player - the format reader (which parses a .mid or .hmi file or whatever), the MIDI engine (which converts MIDI commands into OPL commands) and then the OPL synth itself.
The format parser simply reads a .mid/hmi/etc. file and converts it into a stream of MIDI commands. This is the redundant part, because it is the same for all MIDI players. The MIDI engine converts the stream of MIDI data into OPL commands, working within the limitations of the OPL chip. I think it is this part that should be made available externally. This would allow existing MIDI plugins to play MIDI files through AdPlug, and AdPlug wouldn't have to know about the file format, saving duplication of effort.
FWIW this is how I have implemented the work-in-progress MIDI support for the XMMS2 player. The MIDI plugin reads .mid and other files and produces a stream of MIDI data, then the FluidSynth plugin accepts the MIDI stream and produces PCM data to be played. The AdPlug plugin also accepts the same MIDI stream and produces PCM data, so XMMS2 can be configured to use either FluidSynth or AdPlug as its MIDI synthesiser, yet neither of these two plugins need to know anything about MIDI formats. You can add a new MIDI file format to the MIDI reader plugin, and immediately it can be played through both the FluidSynth and AdPlug plugins.
I think this is the most efficient way to implement such a system (to avoid duplicating code between plugins.)
Except that current AdPlug code base also includes media player plugin components, but FluidSynth does not host any plugin project, and its application list[1] does not include any types of plugin that are also supported by AdPlug. The WIP MIDI support for XMMS2 is at best only adding another plugin type for AdPlug, and not benefiting any existing AdPlug plugin projects in near future[2]. For the AdPlug->FluidSynth plugin be beneficial to AdPlug end users, the FluidSynth plugins for media players need to be produced first. Even then, there are performance issues for running plugin on top of another plugin.
[1] http://sourceforge.net/apps/trac/fluidsynth/wiki/Applications
[2] While Adplug/XMMS plugin may still work in XMMS2, it is not a viable support target for Adplug because XMMS is no longer in development, and the xmms.org is no longer controlled by 4Front or XMMS2 community, while the new site owner seems to be interested in doing anything but further developing XMMS[3].
[3] http://tobias.hieta.se/2010/04/28/what-ever-happened-to-xmms-org/
In regards of XMI support, John Miles of Miles Design, Inc. released SDK for the version 2 of IBM Audio Interface Library, precursor of Miles Sound System driver by RAD Game Tools. The SDK includes source codes and specifications for XMIDI format, OPL/MPU/MT32 sound drivers, miscellaneous tools. Best of all, it comes with a more liberal licence than the MAME OPL code, so the plugin code can be (more) free from the MAME's no commercial usage policy.