Difference between revisions of "OpenTasks"

Jump to navigation Jump to search
2,549 bytes added ,  18:09, 22 February 2011
→‎MIDI device configuration: Update MIDI device configuration task.
(→‎Audio output selection: Update "Audio output selection" description, since we actually only show output devices right now.)
(→‎MIDI device configuration: Update MIDI device configuration task.)
Line 283: Line 283:


=== MIDI device configuration ===
=== MIDI device configuration ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:LordHoto|Johannes Schickel]]


''Background:''
''Background:''
Line 289: Line 289:
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...).
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...).


Right now, the MIDI drivers (and more generally, audio drivers, see the previous task) are treated by ScummVM in a rather simple minded fashion: Either a driver is linked in and hence "available", or not. It's not possible to configure anything about them (like ports to be used etc.), nor does it ever take into account that a single driver might correspond to multiple devices (after all, you can plug several sequencers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator). These two issues are very tightly related.
Unlike the audio driver output selection task above, this task solely focues on configuration of the individual ''MIDI'' devices.


<span style="color:red">TODO improve and extend description, and integrate it better with the Audio output selection task</span>
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.


Some more details can be found on the [[Music drivers redesign]] Wiki page.
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 [[OpenTasks#Audio output selection|Audio output selection task]] in a single Google Summer of Code project!


''The Task:''
''The Task:''


* Add an API for querying the OSystem backend for a list of available MIDI devices (not drivers).
* Design a efficient way to query supported configuration options from a driver / device.
* Information about the selected device must be serializable, so that it can be stored in the config file.
* Design a efficient way to save supported configuration options for a driver / device.
* Selection of devices via command line should be possible.
* 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).
* 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.
* Devices should be configurable via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion.
561

edits

Navigation menu