feature: mastering limiter

[coderofsalvation]

This (optional) very transparent limiter allows milkytracker to:

• output beefier, normalized mixes (the final wav-render (*))
• and/or patterncapture (sampleeditor)
• and/or during realtime playback (**)

In simple terms: milkytracker is now able to always prevent audible clipping.

* = as pointed out in https://github.com/milkytracker/MilkyTracker/pull/283 summing same-rows note-on's easily produces unwanted peaks, resulting in weak mixdowns after normalizing.

'* = playing multiple modules at the same time (liveperformance) will no longer cause peaking-problems () (playing 3 techno-tracks at the same time with same bpm e.g).

This feature also helps in knowing how your mod will sound when played back on broadcasted media, especially for dancemusic (drums) this is pretty important. Setting drive to 2 will most of time output a well-balanced mix, by gently increasing soft parts & decreasing peaks (this change in loudness can be seen in the master vu-meter). The default(!) value is 0 disables the limiter, to always ensure an honest module-playback startingpoint.

Background

Based on all thoughts & feedback on the initial mastering section-idea (https://youtu.be/as9Ii0pt8dE?t=144), the fat has been trimmed to only one slider (ditching saturation modes, as there isn't much to saturate after limiting). Also the 'mono mix'-feature is redundant because ctrl-shift-v (pattern capture to sample-editor) does this already.

The code is actually just Limiter.h along with code which makes sure the slider-value can cascade into the right places, and respond to mixingrate/buffersize changes.

[sagamusix]

I have to say that I'm heavily opposed to such sound colouring features being presented as global settings. People will enable and forget them, and then will be disappointed to realize that after releasing their song, it sounds like crap in any other XM player because it still clips there. ModPlug had the same issue with its global pre-amp that was not saved in files (and strictly speaking FT2 itself had the same issue with the driver pre-amp setting). What would be much better is actually warning the user that output is clipping, so that they can adjust their tune. Alternatively, if this was a playback setting that would be reset when loading new files, it could serve as a temporary way of rendering a soft-limited WAV file of the track, without giving the impression that the XM file itself would be soft-limited when being listened to in another player.

[coderofsalvation]

hm thanks for your comment, I do understand your concerns and highly respect all your years of experience. I also really like your suggestion about resetting it when loading new files (I will immediately implement this as a default global setting).

TBH I'm not sure whether I totally agree with your assumption that most endusers want to release an XM module to replay in other environments. For example, since the first amiga protracker I have met many endusers who have never cared about that, rather the endgoal was to record it to tape, later CD, later wav, mp3 and so on. Actually, with this same goal I've also always used modplug solely as a vst tracker, only sharing the final .wav.

I can imagine the same mindset for (an increasing amount) of raspberry-endusers who want to simply make music, and render it to .wav.

Honestly, I think the different types of end-users have grown over the years, which makes ultimate global settings a tricky topic. As you know, what might be appealling to newcomers might annoy diehard protracker-users and vice versa.

I think with your reset-suggestion, it'll be the sweet spot because there are endusers who do need this, and (their environment) cannot afford milkytracker to become a pluginhost. Again, thx for your feedback and suggestion.

[sagamusix]

Without doubt those people exist, but seeing how vibrant the community that shares and uploads XM files still is (and quite many of them being made with Milky), you have to assume that people that use MilkyTracker "professionally" are in the minority (because you don't hear from them very often, if at all), and that it is important to keep XMs created by MilkyTracker in a "shareable" state. People can wish for a lot of things, but you have to keep in mind that XM is an open format supported by a wide variety of applications, you cannot just go ahead and add a feature to one of those applications that will not be supported by other applications - the past of ModPlug has shown how messy the whole situation becomes very quickly, and undoing such a mistake is almost impossible. The correct way to address such features would be to add a custom MilkyTracker format that can have all those bells and whistles, storing the state of the feature (on/off and drive) in the file itself. Even for people that just make music "for themselves", they would certainly prefer if any playback-related parameters would be part of each individual file and not a global setting in the music software that they can forget to enable or disable, so that even a year later their file still sounds intended after reinstalling a new version of the application with completely different settings.

[coderofsalvation]

hm this vibrant community vs some supposed unmeasurable minority..I don't know man, tricky comparison. Enforcing XM-sharing-as-primary-goal for milkytracker endusers (and the audiences of those endusers) seems a bit biased and idealistic (eventhough I love the idea of a world where everybody consumes music thru XM-files). Imho that ship has sailed as soon as a tracker exports to more popular formats like .wav (a more popular "shareable" state?). Also, lets separate producers & consumers here, and agree that the producer has to take final responsibility for the output(format, and how it sounds in other environments). Also, it seems that time has shown, that external settings/features are needed in music software which are not stored in the moduleformat (playback samplerate, interpolationtype, volume ramping and so on). Maybe that's a good thing, even from a xm-sharing & lifetime point of view (instead of inventing new fileformats). At the end of the day I find a limiter very innocent, even more innocent compared to interpolation-type, volumeramping, surround sound-, equalizer- or bassboost-setting etc. I do agree with a lot of your concerns, however I would kindly ask you to try it, it is probably not as 'coloring' as you think.

[coderofsalvation]

Ok I've added your suggestion, as you can see loading up new modules will reset any limiter setting. This is the default now. I'd say this is win-win! Thx again for the feedback. Ps. would love approval from other maintainers as well, otherwise I have to take these kind of features into a different direction (forking milkytracker into a different project e.g)

[minidcon7]

Ok I've added your suggestion, as you can see loading up new modules will reset any limiter setting. This is the default now. I'd say this is win-win! Thx again for the feedback. Ps. would love approval from other maintainers as well, otherwise I have to take these kind of features into a different direction (forking milkytracker into a different project e.g)

That's the good way to do it. @coderofsalvation I'm explore your "pull requests" and I can't understand Why are they not accepted?.

[coderofsalvation]

step by step: release candidate 1.05 will contain more of them.

[coderofsalvation]

merged in https://github.com/milkytracker/MilkyTracker/tree/rc/1.05