I won't be going through 700kb of 68k assembly to write a mod loader, seriously. If there is no textual format description, you are pretty much out of luck.

Could you leave this open in case somebody else wants to look into it?

I didn't even close it but do you seriously think there are thousands of people out there just waiting to translate 50,000 of mostly uncommented assembly code to C++? Let me give you a realistic answer: No, there aren't. In fact I couldn't even find a hint where the player code would be hidden in this gigantic pile of code, if it's in there at all.

http://aminet.net/package/mus/play/SymphoniePlayer

This is a Java-based player for Symphonie modules (including source) by the author of the original tracker, which contains much easier-to-follow code for loading modules. I haven't used this tracker at all so I don't know how easily convertible the modules are, but if somebody wants to attempt it, check out src/symreader/ImportSongSymphonie.java.

After looking at the player some more, I think I can take a crack at writing a symmod loader sometime soon.

Before I do, though, is the fact that there would now be more 32 MODTYPE flags going to be a problem?

Technically we could probably use a 64-bit enum. However, I wouldn't be too happy with that either. Many formats don't really need this flag (especially all the MOD-like ones) so I would like to solve this issue in a different way. However, this shouldn't stop you from writing a new loader, as I will take care of that.

In particular, MOD_TYPE_WAV and MOD_TYPE_UAX are completely bogus anyway. I think I already have a working copy lying around that does remove them. I guess I should finish that work now.

Is it even currently possible for a module to have more than one of the type flags set at the same time? It doesn't seem like this is ever actually done anywhere, unless I'm missing something.

AFAICS it is not possible to have multiple MOD_TYPE flags set for a single module, but I think it had been possible (or had been planned to be possible) in the past.
In any case, changing that requires modifying a ton of places doing if(GetType() & (MOD_TYPE_IT | MOD_TYPE_MPT | MOD_TYPE_DBM)) or similar. It is also worth noting that converting these bitwise flag bits tests to an actual logical tests of enum values would produce way more code. This could have performance implications if we are actually checking these in the mixer code (which I think we luckily do not).
In any case, the easy step is removing the bogus type flags, and the next easy step would be just using 64 bits instead of 32 bits. The long-term solution is to actually use enum values instead of flags, but I do not think there is currently any pressure to do that right now.

There never was more than one of those flags set at once, but I wanted to leave the possibility to do so, if ever required (though with m_playBehaviour we probably do not need that nowadays). As seen in manx' example, we use these flags to quickly check module capabilities of several formats at once, and the code would become much less readable if we had to do this using e.g. std::bitset or tons of GetType() == MOD_TYPE_IT || GetType() == MOD_TYPE_MPT || ...).

Alright, that makes sense. I went ahead and started using 64-bit MODTYPE for the time being, but I guess it won't be a problem once the unneeded values are removed and I can switch to using one of those instead.

UAX/WAV MODTYPEs have been killed, so updating to the latest revision should make it easy to write a new loader. :)

Slightly off-topic, I have added a new document to the repository, doc/module_formats.md, which contains general hints on writing module loaders (you may recognize some of those from the discussions on your STP loader). I have been dealing with this code for a very long time so things that seem obvious to me might be missing. If you have any specific hints that should be added to this document (e.g. stuff that was not obvious to you when starting to write those loaders), let me know!

The list looks pretty good to me so far. One more thing that might be worth mentioning is how FileReader can be used to treat a portion of another file or a region of memory as its own independent file, which has been useful in loading samples and other data from Symphonie modules (in addition to raw samples they can also contain WAV, IFF, etc. files, and they also sometimes have to be decompressed into memory before being passed to the normal sample loading functions).

There's probably more I'm forgetting from my previous two loaders, but that was recently on my mind anyway.

@Revenant are there any updates on your porting progress? There is some interest in implementing support for this format in HippoPlayer and that player already uses libopenmpt as one of its playback sources, so I guess it would be nice to have this format playable via libopenmpt.

I'd made a fair amount of progress some time ago, though I guess I'm probably a good year and a half or so behind on upstream commits at this point, so I'll have to get up to date and make sure everything still works okay.

I can't promise 100% support for all modules, since there are simply some features of the tracker that would be a bigger effort to implement correctly (namely the stuff involving 'dynamic instruments' or whatever they're called, which allow stuff like synthesizing multiple other samples/notes into new instruments at load time), but I seem to remember that most of the modules I tried (from modland) were playing back fairly well (in many cases even noticeably more accurately than the official Java-based player mentioned earlier), so I think it's pretty close to usable aside from missing a few less commonly used features.

Anyway, I'll try to get up to date with the current upstream sometime soon and do some more testing with the modules I have available and see how much I think still needs to be done on this.

How's the loader going? :) If you think that the only thing that's required is making it work with upstream (there have probably been a few changes here and there that will require some minor changes), I can help with that.

Ouch, where does the time go...

I'll see what I can do sometime within the next week or so.

Hi Revenant, are there any updates on the loader?

I didn't really have time to try bringing my changes up to date after all, so once I get home from Christmas I will probably just push my existing changes to GitHub or something along with some notes. Hopefully after that it should at least be not too much more work to get things going again later.

https://github.com/devinacker/openmpt/commit/ea89d3090ecc2509b7505f41575b2f40a74bca0b

This should be everything I had been working on back in 2017. It's probably still a little messy and experimental but hopefully still workable. I can try doing more with it whenever I get time.

Thank you! I will have a look ASAP.

FWIW, here's just the loader, brought up to current standards so it compiles and works fine:

Some general updates including bugfixes. I also started looking at the echo/delay DSP code in the Java player, which we may also be able to handle.

I should add that there are so many loose ends though that it's unlikely that this will make it into OpenMPT 1.30 (which will already feature two new module formats). I'll rather spend the time to make it sound as good as possible (including DSP) and have it in 1.31.

Thanks, that sounds reasonable to me. I'll check out your changes sometime soon.

I think the only other thing of note I had been doing here (aside from the loader itself) was adding support for 16-bit and/or stereo IFF samples, which some of these modules do use, though I don't remember which ones anymore.

Yep, I already put the 16-bit stuff to be committed separately (would be useful even without SymMOD support), I will commit that soon.

This DSP stuff is rather confusing... I will summarize what I have found but if this contradicts anything you might have found yourself, please let me know!

• The Java DSP doesn't really map to the tracker echo / delay settings at all. It has echo, cross-echo, delay and cross-delay while the echo in the tracker alone has normal, cross, cross2 and center settings. I tried starting from the Java code but I quickly dropped it.
• cross and cross2 seem to the same thing except that the feedback parameters are 100,50,25,... and 50,75,87.5,... respectively.
• While you can manually enable and modify effects from the "System Control" window, those settings are not stored in the file at all.
• The Echo DSP is straight-forward, the Delay DSP seems... strange? It generally shows the same parameters but when it works at all, it does so in a weird way. From my observation, it only clears and updates the delay line if it's set up in the "System Control" window. I will just treat it the same as the Echo DSP for now.

For the one SymMOD out there that uses Transwaves... they are now implemented. Including many more changes as usual.

Lots of progress since the last update... I think all loadtime sample manipulation (fading, overamplification, filters) is now implemented more or less correctly. Virtual instruments are mixed at loadtime. Tons of other findings from studying the original assembly code in more detail.

Nice, thanks again for all the updates! I'll take a look at the latest loader soon.

Current state with a few more bugfixes. I'm inclined to add this to OpenMPT 1.30 after all - most SymMODs seem to be played with sufficient accuracy (especially considering that there isn't really any alternative out there apart from the tracker itself), and I'm currently specifically fuzzing the SymMOD loader to make sure it's safe.

This loader is now finally in trunk as of r14381! Many thanks again to Revenant for your fantastic work on getting this started. It's probably not perfect yet, so anything that doesn't sound quite right yet should be reported in a new issue.