The primary reason for this is to avoid dealing with FluidSynth's rather messy compile setup.
This also protects us from breaking API/ABI changes like between version 1 and 2.
This still needs work for Linux/macOS to deal with glib. Windows works fine.
The method open_file use read text flags to open a file and it fail to check the header of the gus patches, by setting the flag to read binary fix the issue.
- fixed gus emulation not working with DMXGUS and DMXGUSC lump
- gus_patchdir and/or ULTRADIR variable can be used to load custom gus patches together with main patches set with midi_config (not required when using DMXGUS(C) lump configuration)
- gus_patchdir and ULTRADIR variable can be used with both DMXGUS and timidity configuration when using GUS emulation
- fixed wildmidi emulation not working with collection of gus patches (resource files)
- removed sf2 files from midi_config items for gus emulation (when using sf2 with gus emulation the sound is distorted), only resource files will be listed to be used with gus emulation.
- removed the `already loaded` check from timidity setup in order to recreate the reader even when changing the gus memory.
- Allow ZLIB::ZLIB target to be provided by a unified build
- Added ZMUSIC_INSTALL variable to allow disabling of install rules (mostly due to how install(EXPORT) works)
- Static libraries don't need dllimport/dllexport on Windows
- Fixed: INTERFACE include directory was missing from zmusic/zmusiclite targets when using with add_subdirectory
- use_fast_math CMake function updated to allow source files to be passed (for GZDoom/Raze)
1. No longer excludes builtin MIDI passthrough ports.
2. "GZDoom" references changed to "ZMusic Program".
3. No longer bugs out when MIDI playback is paused.
- Prefer target properties instead of setting variables whenever possible.
A zmusic-obj target now exists to represent the commonality between zmusic
and zmusiclite.
- Factored out as much as possible from global settings to per target settings
which will make it easier to support using ZMusic as a submodule. Moved
helper functions into a ZUtility.cmake module.
- We now generate and install ZMusicConfig.cmake so find_package(ZMusic)
will work either automatically or given ZMusic_DIR is set.
- CPack is enabled although some refinement is still needed.
- Requires CMake >= 3.13 which is newer than I would normally like, but given
how no one like to refactor these things it may be better to deal with the
short term pain of going a little aggressive on the requirement in order to
avoid having to make things ugly. Especially given that these scripts have
a tendency to be copy/pasted into sister projects. CMake itself has very few
dependencies so users of old Linux distros should be able to easily compile
a supported version of CMake.
- On Windows CMake >= 3.15 is required for redistributable results.
- Cleaned out bits that were copied from GZDoom but not relevant to ZMusic.
Different volume models were means louder or quiter sounding of the rest of notes in the song. And to avoid the mess between volume models, let's use different gain factor for each volume model?
After a small set of tests, it's fine to use the "AUTO" volume model by default.
Every embedded bank and every WOPL file has a setting of a volume model that matches to the behavior of the original OPL2/3 driver of each volume model.
If the same global variable is used by executable that linked to ZMusic dynamic library, both definitions may clash
For example, Linux builds of GZDoom and Raze could crash on exit because of double free, std::string destructor was called twice on the same module_progdir variable
