Music drivers redesign

Here are the notes about the upcoming music drivers redesign. This starts with the aim to generalize the music driver managing code and enabling custom configuration options for each driver, while simplifying the usage from the engines.

It should also be made possible for a driver to correspond to multiple devices (like, the windows, coreaudio, coremidi etc. drivers, which could indeed access multiple real MIDI devices).

Furthermore, we need to distinguish between drivers/devices on the one hand, and music driver types on the other. In our current code base, these concepts are not properly separated, which leads to awkward code in places and some things are more difficult than necessary or confusing to accomplish.

Music drivers types (interfaces)

• AdLib (MDT_ADLIB)
• FM Towns (MDT_TOWNS)
• PC Speaker (MDT_SPKR)
• PCJr (MDT_PCJR)
• Apple II? (MDT_APPLEII?)
• MIDI
  • GM (MDT_GM)
  • MT32 (MDT_MT32)
  • GS (MDT_GS)
  • ...?
• Digitized/CD-Audio (MDT_DIGI?)
• ...?

Usage from the engines

There are two proposals currently. The first one delegates all the work to the music driver manager involving just one call to it which already returns the music driver created depending on the settings, and it just has to be casted to use it. This ensures a coherent behaviour through all the engines:

musicdriver = MusicDriverManager->createDriver(MusicTypePreferenceList(MDT_MT32, MDT_ADLIB, MDT_SPKR));
switch (musicdriver->type) {
case MDT_ADLIB:
  adlibdriver = (MusicDriverAdlib *)musicdriver;
  ...
}

The other proposal looks like the current implementation and it involves two calls to the music driver manager: the first one to ask what driver will be used, and the second one to create it:

musictype = MusicDriverManager->getMusicType(MusicTypePreferenceList(MDT_MT32, MDT_ADLIB, MDT_SPKR));
switch (musictype) {
case MDT_ADLIB:
  adlibdriver = MusicDriverManager.createAdlibDriver();
  ...
}

Music driver implementations

• NULL driver (Reported as anything, one of the requested types, the most preferred, for example)
• Emulators
  • AdLib emulator (MDT_ADLIB)
  • FM Towns emulator (MDT_TOWNS)
  • PC Speaker emulator (MTD_SPKR)
  • PCJR emulator (MTD_PCJR)
  • MT-32 emulator (MTD_MT32)
• Native midi drivers (Reported as MTD_GM, MTD_MT32... depending on the configuration)
• Wrappers / Mapping
  • GM->MT-32 wrapper (MTD_GM)
  • GM->AdLib wrapper (MTD_GM)
  • GM->PC Speaker wrapper (MTD_GM)
  • MT-32->GM wrapper (MTD_MT32)

Configuration from the user interface

• General configuration:
  • The user can configure the default options of the drivers/devices (This ALSA device is an MT-32 and use this volume, the FluidSynth driver should use this soundfont file, ...)
  • The user can prioritize the music types globally (i.e. I prefer GM, then AdLib, then PC Speaker, and nothing else) and the default driver/device for each type
• For each game:
  • The MetaEngine offers an API for querying which music types are supported by a given target, in order of preference and the user can choose one of those (default will use the previously configured priorities)
  • The user can manually choose an output device and configure it

Which engines use which music type?

• Engines using no MIDI at all:
  • drascula
  • tucker
  • sword1
  • sword2

• Engines using MIDI and without any special AdLib support (so they use the AdLib driver at most as a cheap MIDI "emulator"):
  • agi
  • agos
  • draci
  • m4
  • made
  • mohawk
  • parallaction
  • teenagent
  • tinsel
  • touche

• Engines which seem to have custom code to deal with AdLib
  • cine
  • cruise
  • gob
  • groovie (it just loads custom instruments, nothing fancier)
  • kyra
  • lure ??
  • queen
  • saga ??
  • sci
  • scumm
  • sky

• Engine using MDT_PCSPK
  • agi
  • kyra
  • sci
  • scumm

• MDT_TOWNS and MDT_CMS are *only* used by SCUMM. Kyra has custom FM-TOWNS code.

• MDT_TOWNS can probably be removed -- it should only be enabled for FM-TOWNS games anyway.