2,051
edits
Difference between revisions of "OpenTasks"
Jump to navigation
Jump to search
m
→Output selection: cleanup
m (→Output selection: cleanup) |
|||
| Line 242: | Line 242: | ||
''Background:'' | ''Background:'' | ||
Right now, our API for selecting an audio output is pretty limited. It basically does not differentiate between the different output types (think of MIDI, AdLib, (PC) Speaker, Amiga etc.), | Right now, our API for selecting an audio output is pretty limited. It basically does not differentiate between the different output types (think of MIDI, AdLib, (PC) Speaker, Amiga etc.), which results in a rather confusing way to select the output device, both for the engine code and for the user in the GUI. | ||
Currently we use some (pretty simple and stupid) detection method based on audio output flags given by the engine. These flags contain the supported output types. Albeit that is theoretically fine, the problem is this detection does not include all the above mentioned output types, for example it does not allow to specify "Amiga", which recently turned out to be a major problem for the WIP SCI engine, since its Amiga games support both MIDI ( | Currently we use some (pretty simple and stupid) detection method based on audio output flags given by the engine. These flags contain the supported output types. Albeit that is theoretically fine, the problem is this detection does not include all the above mentioned output types, for example it does not allow to specify "Amiga", which recently turned out to be a major problem for the WIP SCI engine, since its Amiga games support both MIDI (in this case, MT-32 MIDI) and Amiga sound output. Now there is no (clean) way of checking whether the user wanted to use Amiga sound or MT-32 MIDI. Next it does directly map to some concrete backend implementation (like ALSA or Windows MIDI for MIDI). This results in an unclean way of checking in the engine what exactly the selected output type is (this might be required to load special music data files for the different output types). | ||
For the user we currently always show all concrete output implementations (except digital sound!) in the GUI. This is rather annoying, especially since it also shows outputs, which may not be supported by a specific game. | For the user we currently always show all concrete output implementations (except digital sound!) in the GUI. This is rather annoying, especially since it also shows outputs, which may not be supported by a specific game. | ||
| Line 250: | Line 250: | ||
To overcome these issues it would be best to change our audio output configuration API to use different layers of configuration: | To overcome these issues it would be best to change our audio output configuration API to use different layers of configuration: | ||
* The first layer would be the output type. This might be for example MIDI, AdLib (or rather in generic OPL* output), (PC) Speaker (this might also include | * The first layer would be the output type. This might be for example MIDI, AdLib (or rather in generic OPL* output), (PC) Speaker (this might also include PCjr and CMS that would need to be determined in detail), Amiga, Digital Output etc. Note that this is no final list, this would need to be rechecked when working on the task later! | ||
* The next layer would be either a concrete output implementation, like Windows MIDI or ALSA for MIDI, or some sub- | * The next layer would be either a concrete output implementation, like Windows MIDI or ALSA for MIDI, or some sub-type, for example MIDI usually comes in either MT-32 MIDI or General MIDI (or both!). Here would be thought required to determine what would be the best solution. For example some games might just support MT-32 MIDI or General MIDI, thus this might be a first layer type. So if you plan to take this task, you will still have a lot of research to do, to find the best separation :-). | ||
The exact same layers should also be visible in the GUI configuration to allow for a much more user friendly output configuration. The user might additionally configure a concrete output like ALSA to use a specific implementation specific setting (like in the output port for ALSA) though. See the [[OpenTasks#MIDI_device_configuration|MIDI_device_configuration]] task for more information about this. (Note that it would probably best to tackle both tasks in a single Google Summer of Code project!). | The exact same layers should also be visible in the GUI configuration to allow for a much more user friendly output configuration. The user might additionally configure a concrete output like ALSA to use a specific implementation specific setting (like in the output port for ALSA) though. See the [[OpenTasks#MIDI_device_configuration|MIDI_device_configuration]] task for more information about this. (Note that it would probably best to tackle both tasks in a single Google Summer of Code project!). | ||
Of course this is not set in stone yet | Of course this is not set in stone yet; if you have some other great idea how to tackle this, we are happy for your feedback :-). | ||
''The Task:'' | ''The Task:'' | ||
| Line 263: | Line 263: | ||
* Adopt the GUI to reflect the changes. | * Adopt the GUI to reflect the changes. | ||
* (Optionally) also extend all engines to supply a list of supported audio devices for a specific game target. (This would be done via the help of engine authors). | * (Optionally) also extend all engines to supply a list of supported audio devices for a specific game target. (This would be done via the help of engine authors). | ||
* All configuration must be | * All configuration must be serializable for our configuration file. (And it would be nice to have some auto update feature for old configuration files!) | ||
=== MIDI enhancements === | === MIDI enhancements === | ||