This is necessary to write a universal, device independent wave dumper for MIDIs.
With each format inheriting from the main player class it is not possible to create a generic dumper player.
PathExpander has been integrated into the sound font manager and PseudoMidiDevice was only used as the base class for the old Timidity++ device with the external executable.
This isn't supported with the OpenAL backend, and instead of trying to make a
workaround for it, a better approach would probably be to make a FileReader
implementation that handles URLs.
- added arrays to the config to hold entries for the softsynths' config files. This is not active yet, but will later be used to give the user a list of config options instead of having to type it by hand.
The idea is to have more control on the game side instead of dealing with these formats in the backend, which was done for FMod because it already had the decoders implemented.
However, with OpenAL this setup makes no sense and only complicates future extensions that can be better handled at a higher level.
A major part of this device's implementation details about how to handle the callback were not encapsulated by the device class at all, they were #ifdef'd into the streamer class.
This puts everything into the device class which now exposes a clean interface to the rest of the game with no special handling aside from calling two additional virtual functions that are empty for the other devices
* make the critical section local to the respective platform instead of polluting everything with system specific symbols.
* moved system specific class declarations into the source file instead of having them in the global header.
This commit temporarily disables the Windows system device because it cannot be done without polluting the global header and still needs a bit of refactoring.
The approach being used here caused the entire sound system to be infested by windows.h, just to avoid copying around a handful of variables in one place, effectively preventing any compiling optimization.
Windows will now use the same internally defined structure for all MIDI processing which only for actual submission to the system player will be converted to the internal format.
- Replaced GTK/OS X (note different from Cocoa) clipboard code with SDL clipboard API.
- Removed requirement to link to GTK in order to compile with GTK support.
- GTK is no longer init'd if the GTK IWAD picker is not used.
- Our usage of GTK is such that the dynamic loader can work with both GTK2 and GTK3 depending on what's installed.
- Since we're accumulating a lot of library loaders I've built a generic interface as FModule which replaces TOptWin32Proc and the loaders in the OpenAL and Fluidsynth code.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
* OPL: specify the core to use for playing this song
* FluidSynth: specify a soundfont that should be used for playing the song.
* WildMidi: specify a config file that should be used for playing the song.
* Timidity++: specify an executable that should be used for playing the song. At least under Windows this allows using Timidity++ with different configs if the executable and each single config are placed in different directories.
* GUS: currently not operational, but should later also specify the config. This will need some work, because right now this is initialized only when the sound system is initialized.
* all other: no function.
These options should mainly be for end users who want to fine-tune how to play the music.
Instead of the previous method where there'd be a filename and offset, and/or a
memory pointer, this uses a class to access resource data regardless of its
underlying form.
should ignore any tempo events in XMIDI songs that were left over from the original MIDI
files, since the converter didn't remove them.
SVN r3384 (trunk)
