Difference between revisions of "OpenTasks/Audio/MIDI Device Configuration"
(Move OpenTasks onto unique pages with an Infobox and Category so we can collect them all up onto a summary page.) |
(No difference)
|
Revision as of 17:52, 4 March 2011
Open Task | |
Task Name | Untitled |
Technical Contact(s) | Johannes Schickel, Max Horn |
Subsystem | Audio |
Background:
Many of the adventures supported by ScummVM make use of MIDI music. Which is why we already include several device drivers for various MIDI APIs and emulators (e.g. ALSA, Windows MIDI, Mac OS X CoreAudio/CoreMIDI, fluidsynth...).
Unlike the audio driver output selection task above, this task solely focues on configuration of the individual MIDI devices.
We have a few game specific settings, like "True Roland MT-32" mode or "Roland GS Mode", currently. In reality these are not settings of an individual game, but rather of a specific MIDI device. Think of it like this: When you connect your Roland MT-32 device to your first ALSA hardware MIDI port, it is pretty obvious that this device will only support MT-32 MIDI data. Currently whenever you select that MIDI device in a specific game you also have to make sure that the "True Roland MT-32" mode setting is selected, otherwise it might be that the game will send General MIDI data to the Roland MT-32, which in turn will result in odd output. This is especially annoying if you want Roland MT-32 output in a few selected games and General MIDI output in others, this way you will have to make sure that in every game's settings the device and its type are setup correctly. As you can easily see this is lots of redundant configuration effort and easy to forget.
The idea of the task now is to change the configuration of these aspects to the device layer. This means the user should have the possibility to set a certain set of options on a per device base. Think of it like this: The users has "MIDI Port 1", where is Roland MT-32 is connected, on the other hand he has "MIDI Port 2", where a General MIDI synthesizer is connected. Now the user should have the possibility to configure his "MIDI Port 1" device as "True Roland MT-32" and his "MIDI Port 2" device as "General MIDI" device. Now when he selects "MIDI Port 1" in a game it will automatically be recognized as Roland MT-32 by the game and thus the user will not have to do any special configuration in the game's settings for his output device. The same is of course true for his "MIDI Port 2" device.
In reality it is a little bit more complicated though, since we feature special devices like the "MT-32 Emulator", which of course only supports MT-32 data, thus it should not be possible to change its configuration to General MIDI, or the "AdLib Emulator", which is a General MIDI(?) emulator, here of course it should not be possible to reconfigure it as a MT-32 device. Furthermore we have certain MIDI type options, which are not present in the current GUI, like for the Yamaha FB01, which is a synthesizer only supported by the SCI engine. And last but not least we support soundfont based emulators like fluidsynth, for those it would be nice if the user could add virtual devices, which for example differ in the soundfont setup, but all get individual device entries in the configuration dialogs. In neither the current driver API layer nor the device API layer it is possible to retrieve any information on whether it is possible to configure a device in a specific way. Thus this needs to be extended as part of this task too.
Note that it would probably be best to tackle this task and the Audio output selection task in a single Google Summer of Code project!
The Task:
- Design a efficient way to query supported configuration options from a driver / device.
- Design a efficient way to save supported configuration options for a driver / device.
- The design must be easy to extend, also it must be possible to add new drivers easily.
- It must be possible to save the configuration to our configuration file.
- Configuration of a device (for single game run) via command line should still be possible.
- It must deal with devices being added/removed (at least between runs of ScummVM, ideally also while ScummVM is running).
- Devices should be configurable via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion.