View Issue Details

IDProjectCategoryView StatusLast Update
0001130OpenMPT[All Projects] User Interfacepublic2018-10-12 14:30
ReporterStarWolf3000Assigned Tomanx 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version8.1
Product VersionOpenMPT 1.28.00.* (current testing) 
Target VersionOpenMPT 1.28.01.00 (goals)Fixed in VersionOpenMPT 1.28.01.00 (goals) 
Summary0001130: [S3M] Add global volume control to mixer for OPL instruments
Description

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

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

Saga Musix

Saga Musix

2018-06-24 10:38

administrator   ~0003562

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.

StarWolf3000

StarWolf3000

2018-06-24 11:04

reporter   ~0003563

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?

manx

manx

2018-06-24 11:38

administrator   ~0003564

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).

Saga Musix

Saga Musix

2018-06-24 12:03

administrator   ~0003565

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?

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.
There are currently two possible ways to solve this:

  • in S3M: use a combination of global volume (can also be set via libopenmpt) and sample volume to adjust the balance.
  • if we are going to support OPL instruments in MPTM at some point, their levels could be controlled through the VSTi volume.

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.

StarWolf3000

StarWolf3000

2018-06-24 14:15

reporter   ~0003566

[...] 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?

Saga Musix

Saga Musix

2018-06-24 14:32

administrator   ~0003567

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.

Saga Musix

Saga Musix

2018-07-09 20:40

administrator   ~0003573

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.

manx

manx

2018-10-12 14:30

administrator   ~0003661

libopenmpt ctl "render.opl.volume_factor" added in r10901.

Issue History

Date Modified Username Field Change
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 (goals)
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 (goals)
2018-10-12 14:30 manx Note Added: 0003661