Hi, while our current approach seems to be working fine for interfaces that support raw MIDI output- usually external sequencers- I wasted several hours today trying to get the same to work with /dev/sequencer (and I also briefly looked at the ALSA way to do this). As far as I can tell, there are two "sane" ways to do this: 1) Copy the code out of playmidi and pmidi (both are GPL'd) and adjust it to our purposes 2) fork() and execvp() playmidi, timidity, or pmidi >From what I've seen, approach (1) is still a lot of work, and, worse, will bloat our code base immensely. I'd therefore suggest (2), even though it won't work on some non-UNIX systems (neither would (1), of course). It does, however, have the following disadvantages: a) Orthogonal to our current sound subsystem approach b) No way to keep synchronized c) Fade-out only by means of global volume controls (b) means that some cues may be slighly off, especially on high system load. I think this is acceptable, since the games will still be fully playable (the alternative, chopping the sound files apart, seems to be even less appealing). (c) is particularly nasty. Using /dev/mixer or an equivalent may well backfire- especially for timidity- once we have sound effects to play. The fastest way to build this would be to resurrect the oldmidi.c code to produce a complete MIDI file (for playmidi) or buffer for piping (timidity, pmidi). If we use timidity, we can pipe the output back again and manually mix it and set its volume (Exult does something similar). Any thoughts/suggestions/volunteers? llap, Christoph
