The main reason I am bringing this up is because different compression systems have loss in different ways and depend entirely on the settings you apply to them, and I think working with those systems instead of ignoring them completely when it comes to samples could be an advantage for (one example) the example modules which ideally need to be tiny to be included with modplug. I am picturing an example module that includes singing throughout the track and is tiny enough not to impact the download much at all - made using a simple toggle within the sample tab instead of some back door system. The last time I tried to make an example module for ompt I think I talked about this in the forum topic and you guys said you have your ways to compress the samples if they are longer etc... so yeah stuff like what you mentioned there, plus the ability to compress the samples to insane degrees working WITH the compression systems could add up to tracks which include vocals and other longer samples being much smaller, maybe even under 500k (in a zip). If we know we will be getting lossy samples, and are willing to eat the loss, then I dont see any problem with it.

I also presume a system like this could throw up a warning dialogue the first time it is toggled or compression is applied to a sample for every module, a kind of disclaimer "By preceding using this option you will be compressing your sample within modplug, with known lossy compression systems, proceed at your own risk!" kinda thing so people know... I think it is obvious enough for something like that to not be necessary, maybe even throw that dialogue up the first time a sample is compressed with that specific install of ompt would be enough. But obviously that kind of thing is entirely up to you guys.

we might even be able to have recommended compression profiles in a system like this like if the sample is specifically vocals of a tenor like myself we could have a compression system that is as lossless within the general range of that kind of voice as possible while being extremely destructive outside that range.
The ideal would be I add my vocals, I mute silences between stuff while working on my normalising step, when done I save that file then make a new mptm file, add compression to the vocal sample from a profile I have made or one we have recommended for tenor vocals and adjust it considering the over all mptm file size I am looking for, then as I exit the options (probably an [Apply] button) it shows me what that sample sounds like with compression in the sample tab - I press q (c-5) and listen to the new compressed sample making sure the settings I applied work ok with it - I can then go back into the compression tab and adjust it again if it ended up too lossy or maybe I dont mind it getting more lossy...
Ok I think this would have to be thought through intensely since in theory with a system like I just described above it would then be writing the lossy sample to the sample slot, but maybe the compressed sample can be stored in a buffer or something until the user hits ctrl-s or presses save... and at that stage it over writes with the lossy sample... I think this kind of nuance to the system would best be contemplated by the team of programmers since you guys would know the limitations etc.

[edit] now that I think about it again... undo will be perfectly fine for stepping back the compression so I can recompress, but ideally it would keep the compression settings I applied the first time so I can tweak them - fuck I can forget some obvious stuff sometimes - I apologise.

I also imagine when the sample is being compressed, a progress bar for the compression progress would be expected.
(just trying to flesh out the system I am seeing in my imagination here guys, but I fully expect you to make things completely different as you decide what is actually needed)

[edit] I am trying my very best to think like a programmer when I put up these feature requests, try to think through the considerations you guys will need to make, so I sometimes meander while trying to be thorough and as considerations occur to me... if you would rather I confine all of these additions to a single reply to my issue, or include all of these in the body of the feature request itself, I can do that in order to not clutter the issue tracker timeline... I apologise if these get too long.

I know of the external samples system in mptm files and I have heard about the IT compression system before in the past, but I dont know anything about it.

Then maybe it's time to learn and ask about this things first before creating a new feature request, really.

External samples can be 3 kinds of uncompressed file and 1 flac file which I presume uses some kind of compression, but will not decrease the over all size of the zip if I want to include the file.

Almost everything in this sentence is wrong:

• External samples can be in any sample format supported by OpenMPT. Nobody's stopping you from using MP3 or any of its more modern alternatives such as Opus.
• FLAC will typically reduce file sizes by around 50%, for vocal samples probably even more. Hence it will also decrease the size of your zip file.

Anything outside of this existing feature is way way way way way way way way way way way too complicated to implement and maintain. Compressed samples cannot be edited, we must always keep a compressed and uncompressed version in memory. UI for different kinds of sample compressors would have to be added. Countless other things I cannot think of right now.

There is already solution, as mentioned above: Compress your samples outside of OpenMPT and then load them back into the application as external samples. This is the officialy supported way of compressing samples (and yes, that's how I post-processed some of the external samples used for example songs. The system works perfectly for that).

(just trying to flesh out the system I am seeing in my imagination here guys, but I fully expect you to make things completely different as you decide what is actually needed)

Please, please, please. You are writing essentially a wall of text here and then make it even longer by adding a minute detail that is irrelevant to the grand scheme of things and that you already expect to be done differently anyway. If we wanted to implemented a system like this (which, as said, we won't), it would probably take several months to implement, it would be an extremely complex feature, and then suggesting that in some part of the feature there needs to be a progress bar is just completely inappropriate. If you want to help, please write shorter requests, not by adding such details. They can always be added later when they are asked for.