[Scummvm-devel] MIDI output "ports"

Max Horn max at quendi.de
Mon Dec 26 04:31:01 CET 2005


Hi folks,

today I want to talk to you a little bit about MIDI output devices  
and how we (not) handle them... and how we might improve this. I am  
hoping on your input :-).

Disclaimer: You have seen me write many such posts in the past. E.g.  
regarding new GUIs, display lists, etc.. Sadly, little happens in  
response to those. I am aware of that, and it saddens me. Truth is, I  
have little time to spend on ScummVM myself these days. My hope with  
these emails is that at least they make issues apparent to other  
people, and the ensuing threads provide guidance for people  
interested in tackling them. Maybe I should move some of those  
discussion (in a condensed form) to the Wiki. Anyway, I can  
understand if you feel bored by these mails, but I still hope that  
they fulfill at least some function... :-/



Problem
-------

Currently, we have multiple MIDI "drivers". Some of those are  
platform specific (e.g. the "windows" or "coreaudio" MidiDriver);  
some of them emulate MIDI by software (softsynths like the MT32 emu  
or adlib), some of them invoke portable libraries (e.g.  
fluidsynth...). We also have a couple very specific ones (pcspk,  
pcjr, towns), but I do not want to talk about those today.

So, we have these output "drivers". They work quite well, but there  
is one major limitation: Each driver exists only once, but in  
reality, might have the potential to map to multiple actual *devices*

For example, on Windows, the "windows" driver always uses the built- 
in windows sequencer (=softsynth). It's (as far as I can tell) not  
possible to use actual MIDI hardware this way. So if you have an  
MT-32, tough luck.

Similar on Mac OS X: The CoreAudio and QuickTime drivers always use 
(d) the softsynth. I changed this today a little bit, there is now a  
new "CoreMIDI" driver which allows using real MIDI hardware/synths.  
It's still limited, however, as it'll always use the first available  
synth. So if a user has multiple, he's screwed again.

The ALSA MIDI driver has the same problem. To overcome it, there is  
the SCUMMVM_PORT env variable (ugh! How evil, passing config options  
via env vars!!!), and also the "alsa_port" config option. Those do  
the job, but clearly they "don't scale", as they are totally specific  
to the ALSA backend.

The seq / OSS driver also uses an env var: SCUMMVM_MIDI, i.e. a  
different var, but has no matching config option.


Ideas
-----
The situation described above is IMO quite bad. Two things should happen
1) Add a unified way to specify "sub-devices" or "ports" for a MIDI  
device
2) Add this to the GUI.

Step 1 should be relatively easy to implement. I have two ideas here:  
Either we use a second config key here, like "music_port" or  
"music_extra_conf".

Or we change the "music_driver" key syntax slightly: Allow a  
"DEVICE:PORT" syntax, similar to how ports are encode in URLs  
(instead of the colon ":" we could of course use any other char). E.g.
   music_driver=alsa:65:0
or
   music_driver=coremidi:My Device Name
This would be trivial to add, just some mods in sound/mididrv.cpp are  
needed to parse/write the "extended" device names. This would also  
make it trivial to pass the port param via the command line:
    ./scummvm -e windows:2 monkey2

After this, we could deprecate SCUMMVM_PORT, SCUMMVM_MIDI, alsa_port  
(and auto-upgrade them to the new form when we see them).

What do you think?


Step 2, the GUI. The easiest way to add support for the new extra  
param (regardless how it is implemented) would be to provide a new  
extra text field which allows the user to specify any string for the  
"port". Not the easiest to use, but quick to implement. I recommend  
we do this first, to have something usable.

Better, but harder, would be to add a way to query the system for a  
list of actual available "devices". We would basically extend  
getAvailableMidiDrivers to not just return a list of driver; but  
rather the list of *devices*. So, the list would still contain one  
adlib driver, one pcspk driver, etc., but possibly multiple "windows"  
entries: One for the windows built-in softsynth, and one for each  
actual MIDI device.

We could also combine both approaches: Off multiple devices from a  
popup, but still allow the user to specify a custom one if they  
insist...


What do you think?



Bye,
Max




More information about the Scummvm-devel mailing list