View Issue Details

IDProjectCategoryView StatusLast Update
0000672OpenMPT[All Projects] File Format Supportpublic2017-02-25 18:55
ReporterAmaroq_Dricaldari 
Assigned To 
PrioritynoneSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Platformx86OSWindowsOS Version7
Product VersionOpenMPT 1.24.02.* (old testing) 
Target VersionFixed in Version 
Summary0000672: SymMOD support
Description

Grant OpenMPT the ability to open modules composed in Symphonie Pro

Additional Information

I have provided a link to a Google Drive download, which contains the Symphonie Pro source code and a SymMOD.

https://drive.google.com/file/d/0B1URcZnhifwbaVVGQzN4OWF5RTg/view?usp=sharing

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

Relationships

Activities

Saga Musix

Saga Musix

2015-04-11 22:25

administrator   ~0002031

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.

Amaroq_Dricaldari

Amaroq_Dricaldari

2015-04-11 22:36

reporter   ~0002032

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

Saga Musix

Saga Musix

2015-04-11 22:42

administrator   ~0002033

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.

Revenant

Revenant

2017-02-20 21:49

reporter   ~0002886

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.

Revenant

Revenant

2017-02-23 02:43

reporter   ~0002888

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?

Saga Musix

Saga Musix

2017-02-23 10:40

administrator   ~0002889

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.

manx

manx

2017-02-23 21:15

administrator   ~0002890

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.

Revenant

Revenant

2017-02-24 01:10

reporter   ~0002893

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.

manx

manx

2017-02-24 09:15

administrator   ~0002894

Last edited: 2017-02-24 11:51

View 2 revisions

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.

Saga Musix

Saga Musix

2017-02-24 11:02

administrator   ~0002895

Last edited: 2017-02-24 12:46

View 3 revisions

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

Revenant

Revenant

2017-02-24 18:42

reporter   ~0002896

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.

Saga Musix

Saga Musix

2017-02-24 20:53

administrator   ~0002897

Last edited: 2017-02-25 18:55

View 2 revisions

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!

Revenant

Revenant

2017-02-24 22:59

reporter   ~0002898

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.

Issue History

Date Modified Username Field Change
2015-04-11 22:20 Amaroq_Dricaldari New Issue
2015-04-11 22:21 Amaroq_Dricaldari Additional Information Updated View Revisions
2015-04-11 22:25 Saga Musix Note Added: 0002031
2015-04-11 22:30 Saga Musix Priority low => none
2015-04-11 22:30 Saga Musix Reproducibility unable to reproduce => N/A
2015-04-11 22:36 Amaroq_Dricaldari Note Added: 0002032
2015-04-11 22:42 Saga Musix Note Added: 0002033
2017-02-20 21:49 Revenant Note Added: 0002886
2017-02-23 02:43 Revenant Note Added: 0002888
2017-02-23 10:40 Saga Musix Note Added: 0002889
2017-02-23 21:15 manx Note Added: 0002890
2017-02-24 01:10 Revenant Note Added: 0002893
2017-02-24 09:15 manx Note Added: 0002894
2017-02-24 11:02 Saga Musix Note Added: 0002895
2017-02-24 11:51 manx Note Edited: 0002894 View Revisions
2017-02-24 12:45 Saga Musix Note Edited: 0002895 View Revisions
2017-02-24 12:46 Saga Musix Note Edited: 0002895 View Revisions
2017-02-24 18:42 Revenant Note Added: 0002896
2017-02-24 20:53 Saga Musix Note Added: 0002897
2017-02-24 22:59 Revenant Note Added: 0002898
2017-02-25 18:55 Saga Musix Note Edited: 0002897 View Revisions