Save in format...

[Metro28]

OpenMPT supports many different formats, but to save a module there are only 5 (IT, XM, S3M, MOD and MPTM). I wanted to know if it is possible to support more (example: MTM, AMS...). What would have to be modified in OpenMPT so that it can be saved in more different formats?

[Saga Musix]

This will never happen for a variety of reasons.
First off, it would require perfectioning the support for each of these formats. Right now the most effort for compatible playback is spent on the formats that OpenMPT can natively edit. The situation is already bad enough as it is, but if there was now the possibility that an MTM file was written either in MultiTracker or in OpenMPT, and someone accidentally makes use of an OpenMPT quirk in their MTM module, then other playback engines would now have to start supporting both playing MTM files the way MultiTracker did and the way OpenMPT did (or the file will just sound wrong forever in any playback engine other than OpenMPT). It's better if some formats stay "dead".
Second, it adds a lot more complexity to the code for practically zero gain. It's not like there are thousands of people waiting to finally be able to save their precious music in AMS format because they want to listen to their music on the go on their MS-DOS laptop and the only software that runs on that laptop is Velvet Studio. Trackers are already a niche in music production, but supporting anything but the most common format is a niche within a niche that probably serves a handful of people at most. For this handful of people, an external conversion tool that e.g. converts IT to AMS would make much more sense if they really have a valid reason to write an AMS file and this is the only way they can do it. But most people don't have this valid reason, and satisfying your curiosity is not a valid reason for me either.

[manx]

Even currently, one could argue that supporting saving especially S3M serves very little purpose in practice. If support wasn't there already from the beginning, we very likely would have never added it.

[Saga Musix]

I wouldn't necessarily say so. Since the addition of OPL support to OpenMPT, the number of S3M files with OPL instruments uploaded to ModArchive has surged, so it's arguably something people have been waiting for and find useful (of course there was Schism Tracker before that, but it doesn't make editing OPL patches as painless as OpenMPT does).  It shows that S3M is all but forgotten due to this unique feature. But of course, many things would be completely different if OpenMPT was made as a new tracker today, a lot of them depending on what the intended focus of such a project would be. But most certainly, supporting the least common formats for native editing wouldn't be its focus.

[Metro28]

This will never happen for a variety of reasons.
First off, it would require perfectioning the support for each of these formats. Right now the most effort for compatible playback is spent on the formats that OpenMPT can natively edit. The situation is already bad enough as it is, but if there was now the possibility that an MTM file was written either in MultiTracker or in OpenMPT, and someone accidentally makes use of an OpenMPT quirk in their MTM module, then other playback engines would now have to start supporting both playing MTM files the way MultiTracker did and the way OpenMPT did (or the file will just sound wrong forever in any playback engine other than OpenMPT). It's better if some formats stay "dead".
Second, it adds a lot more complexity to the code for practically zero gain. It's not like there are thousands of people waiting to finally be able to save their precious music in AMS format because they want to listen to their music on the go on their MS-DOS laptop and the only software that runs on that laptop is Velvet Studio. Trackers are already a niche in music production, but supporting anything but the most common format is a niche within a niche that probably serves a handful of people at most. For this handful of people, an external conversion tool that e.g. converts IT to AMS would make much more sense if they really have a valid reason to write an AMS file and this is the only way they can do it. But most people don't have this valid reason, and satisfying your curiosity is not a valid reason for me either.

Thanks for taking my question, I didn't think it was that difficult.

[mabersold]

OpenMPT supports many different formats, but to save a module there are only 5 (IT, XM, S3M, MOD and MPTM). I wanted to know if it is possible to support more (example: MTM, AMS...). What would have to be modified in OpenMPT so that it can be saved in more different formats?

For the sake of context: at the demoscene's peak, almost all music was being made in IT, XM, S3M and MOD formats (MPTM didn't exist yet). Most of the trackers that were used at the time could only save in a limited set of formats (to save in other formats, you normally had to get the software written specifically for that format). Even then, there really wasn't any reason to save in more formats than any of those four: nobody really wanted that, and those formats didn't provide any benefit that was worth the cost of writing code to support them. I'm guessing that remains true today - it's probably enough work as it is just to support playback of all the existing formats.

[Saga Musix]

To extend on that even more: Many trackers tried to be the next Fast Tracker, or the next Scream Tracker. None of them succeeded, because there was no compelling reason to use them over the existing popular alternative. Today the reasons to use them are even less compelling. Other trackers were simply internal tools of demo groups (a strong case of Not Invented Here syndrome), which again made little sense to be supported by other groups' software.

If there's ever a need to write an converter for a specific format, I may do it outside of OpenMPT (I have done that before). But I certainly won't be writing exporters for the 30+ formats OpenMPT can load, many of which are only partially documented / reverse-engineered so OpenMPT wouldn't even be able to write syntactically valid files for those formats (currently it simply skips over unknown data in some formats).