View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001130||OpenMPT||[All Projects] User Interface||public||2018-06-24 06:35||2018-10-12 14:30|
|Product Version||OpenMPT 1.28.00.* (old testing)|
|Target Version||OpenMPT 1.28.01.00 / libopenmpt 0.4.0 (upgrade first)||Fixed in Version||OpenMPT 1.28.01.00 / libopenmpt 0.4.0 (upgrade first)|
|Summary||0001130: [S3M] Add global volume control to mixer for OPL instruments|
As OpenMPT (testing) now supports FM instruments in S3M, as a future feature it would be nice to have a separate volume slider on the General tab for this kind of sound source (as it is with VSTis and samples). At the moment, only the volume sliders in the OPL editor and the Global Volume do anything in this regard.
This is in addition to Saga's possible features documented in 0000381:0003557
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
This is not as simple as it might sound: There is no way to store this information in the S3M file, and we have to assume somewhat standardized levels for OPL voices to be interoperable. What you can do though is decreasing the global volume of the module. In ST3 this wouldn't affect OPL voices (I think), but it will reduce the volume of OPL voices in OpenMPT at least.
Would it make some sense on the application level (like there's no volume saved for MOD), so opening an S3M with OPL uses a default volume every time?
Precisely because there is no well-defined volume mapping between OPL and sample sounds, such a (mixer) setting is also required for libopenmpt. The very same setting should be exposed as an application-wide setting in OpenMPT (for basically the same reason).
No no no no no, application-wide settings are even worse on so many levels. OpenMPT had application-level pre-amp for samples before and it lead to a big mess because the levels between samples and VSTis (or samples and nonlinear effects) were suddenly depending on the artist's setup and could no longer be standardized between different computers, unless the artist precisely communicated which pre-amp level to use (which noone ever did). We solved this in Mixmode RC3 by no longer taking the pre-amp into account. Having another global setting that changes the interpretation of modules depending on the artist's taste is going to throw us back into the same issues.
What we could do for S3M is allowing the VSTi slider to be used for OPL instruments, but it's not saved in the file. So it's okay to use it for temporary adjustments, but the file will always sound the same when loaded from disk, providing consistent sound between OpenMPT, SchismTracker and ST3 in DOSBox - unless the user explicitly wishes to change this balance by using the global volume slider (or VSTi slider) or applying a different global volume in libopenmpt.
[...] What we could do for S3M is allowing the VSTi slider to be used for OPL instruments, but it's not saved in the file. So it's okay to use it for temporary adjustments, but the file will always sound the same when loaded from disk [...]
This is basically what I meant in 0001130:0003563. Not saving the volume in the file itself (as S3M doesn't seem to support it), just temporary as long as the file is open.
According to http://www.shikadi.net/moddingwiki/S3M_Format there's an 8 byte field in the header that is reserved, but unused. Is OpenMPT actually using it? If not, would it theoretically be possible to store that volume information in that field and read it upon opening?
It has been decided long ago that OpenMPT is not going to butcher formats any more beyond what it already does. Currently there are not really any OpenMPT-specific hacks to be found inside S3M files (16-bit and stereo samples are also supported by many other S3M players) and it should stay this way. It's a difficult issue but it shouldn't be "solved" by adding more incompatible format hacks. In the next weeks I want to get a few more real recordings from FM+PCM in ST3 on older SoundBlaster cards to get to know their volume relation better.
Starting from r10553, it is now possible to temporarily control the OPL volume through the VSTi slider on the general tab. As mentioned above, this value cannot be saved in the file but it can be useful for temporary adjustments during listening.
libopenmpt ctl "render.opl.volume_factor" added in r10901.
|2018-06-24 06:35||StarWolf3000||New Issue|
|2018-06-24 10:38||Saga Musix||Note Added: 0003562|
|2018-06-24 11:04||StarWolf3000||Note Added: 0003563|
|2018-06-24 11:38||manx||Note Added: 0003564|
|2018-06-24 11:39||manx||Target Version||=> OpenMPT 1.28.01.00 / libopenmpt 0.4.0 (upgrade first)|
|2018-06-24 12:03||Saga Musix||Note Added: 0003565|
|2018-06-24 14:15||StarWolf3000||Note Added: 0003566|
|2018-06-24 14:32||Saga Musix||Note Added: 0003567|
|2018-07-09 20:40||Saga Musix||Note Added: 0003573|
|2018-08-18 12:54||Saga Musix||Assigned To||=> manx|
|2018-08-18 12:54||Saga Musix||Status||new => assigned|
|2018-10-12 14:30||manx||Status||assigned => resolved|
|2018-10-12 14:30||manx||Resolution||open => fixed|
|2018-10-12 14:30||manx||Fixed in Version||=> OpenMPT 1.28.01.00 / libopenmpt 0.4.0 (upgrade first)|
|2018-10-12 14:30||manx||Note Added: 0003661|