HunterZ
commented
5 years ago This is now all fixed by pull request #285:
- AdlMidi device now doubles the value of every sample generated by libadlmidi. Even the maintainer of libadlmidi does this in one of his example programs: https://github.com/Wohlstand/ADLMIDI-Player-Java/blob/master/ADLMIDI-Player/src/main/cpp/native-lib.cpp#L66
- FluidSynth device now sets a gain of 0.5 instead of the default 0.2
- Controlling music volume via mixing in the SDL music callback handler has been removed. Instead, I added an implementation to existing sub logic for handling global music volume change notifications. All volume change MIDI controller messages sent to the music device are now scaled according to the global music volume.
The music also now keeps playing the options menu, so that you can make real-time volume adjustments. Both the software synthesizers and native MIDI devices support dynamic volume adjustments via the slider, audio log ducking, etc. in a manner that appears to be consistent with the original developer design and SSEE.
I noticed that AdlMidi for FluidSynth are quieter than all of the native MIDI devices I have available (various hardware and software synths), even when the music volume is set to full.
Also, the native MIDI device currently does not respect global volume, which apparently is maintained in curr_vol_lev. In order to support this, someone would need to tell the music device when the volume changes. Note that it gets changed all over the place, like temporarily when audio logs are being played.
It might make sense to have MusicCallback() in Xmi.c detect changes to curr_vol_lev and turn these into a master volume change call to the music devices. Maybe the volume scaling for AdlMidi/FluidSynth could then be done inside the music device code too, instead of at time of mixing in MusicCallback()? This would make things more consistent across device types.