View Issue Details

IDProjectCategoryView StatusLast Update
0001127OpenMPT[All Projects] Player input plugins (xmp-openmpt, in_openmpt, foo_openmpt)public2018-09-07 18:10
ReporterSlenderAssigned Tomanx 
Status assignedResolutionopen 
Platformx64OSWindowsOS Version10
Product Version 
Target VersionFixed in Version 
Summary0001127: Sample texts in Impulsetracker modules should be exposed in the foo_openmpt message tag

It seems that currently, in the foo_openmpt message tag, for Impulsetracker modules, comments are displayed, and if those aren't found, instrument texts are displayed. I've seen some old modules that will actually write comments in samples rather than instruments, so the message tag only shows instrument names. I believe that sample tags should be included along with instruments in the foo_openmpt message tag.

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




2018-06-10 05:11

administrator   ~0003548

If the song message is empty, we fall back to using the instrument names, if in turn they are completely empty, we fall back to using sample names. Although this heuristics work for most modules, it obviously cannot work for all modules, and I do not see an easy way to solve this.

It might be the case that the module in question only contains whitespace characters in the instrument names, and we could probably include that aspect in the heuristics.

Can you name/provide specific modules where the current heuristic fails?



2018-06-10 08:03

reporter   ~0003549

Yes, (-DF-RND.IT.

Saga Musix

Saga Musix

2018-06-12 13:19

administrator   ~0003551

It is more common in IT files to use sample texts rather than instrument texts for a song message, but of course this is not true for all modules. I guess we have to expose both texts if no comments are found in order to support both possible scenarios. The foobar plugin should probably also somehow expose the sample/instrument texts separately if it doesn't do so already, just like xmp-openmpt.



2018-06-26 19:03

reporter   ~0003569

Update. Here is a more permanent link to the test case I provided in earlier comments.



2018-09-07 12:45

reporter   ~0003611

Slightly related to this, a lot of Protracker IFF files are affected by this as well, though the <message tag there is just exposing several space characters rather than the sample text, example:

Saga Musix

Saga Musix

2018-09-07 17:17

administrator   ~0003612

Last edited: 2018-09-07 17:18

View 2 revisions

We could probably trim the message (and end up with an empty message in that case). I'm not sure if that's always a good idea though, e.g. when the message contains some ascii art and it's important that it appears in a rectangular shape (e.g. if the user renders text with a fixed background color). Either way it's a different issue that would not be solved by the proposed fix for the original issue at hand.



2018-09-07 18:06

administrator   ~0003613

Regarding the original issue, I think it probably makes sense to, depending on module format, try either instrument or sample names first in case the message is empty or non-existent. For IT it is probably more common to use sample names, for XM, it is always instrument names. I am also not opposed to, again depending on module format, just include both instrument and sample names in case of no real message (if that makes sense for some formats).

It might even make sense to just always include everything in the "message" metadata (with ordering depending on the format).

Regarding trimming anything, I am strongly opposed. If the names contain any spaces we should keep them as much as possible. The goal here is not to provide a somehow "optimized" look of what is stored in the module, but instead provide an as identical as possible representation of what is stored in the file.



2018-09-07 18:09

administrator   ~0003614

Or we do all of that and provide "message", "message_heuristics", "message_all", "message_raw", "message_trimmed" ;)

That's probably not very useful. However, no matter what single variation we choose, I think there will always be some files where the chosen solution will not be optimal.

Saga Musix

Saga Musix

2018-09-07 18:10

administrator   ~0003615

I don't think it makes much sense to attach sample/instrument texts to the message metadata if there is already a message text (weird messages like the one in heaven.ptm notwithstanding). Generally I think if a player wants to list both the message and sample/instr texts I think that the player developer should decide the best way to represent them (e.g. with separators between different sections). To be clear, this means of course that foo_openmpt should handle this situation better, and I think that libopenmpt already does the right thing in this case.

But if there is no message, it makes sense to just include both instrument and sample texts for most formats. Maybe not so much for XM and clones where samples belong to instruments, but for IT-like formats where sample and instrument lists are completely separate, it makes sense to list both.

Issue History

Date Modified Username Field Change
2018-06-09 22:51 Slender New Issue
2018-06-10 05:11 manx Assigned To => manx
2018-06-10 05:11 manx Status new => feedback
2018-06-10 05:11 manx Note Added: 0003548
2018-06-10 08:03 Slender Note Added: 0003549
2018-06-10 08:03 Slender Status feedback => assigned
2018-06-12 13:19 Saga Musix Note Added: 0003551
2018-06-26 19:03 Slender Note Added: 0003569
2018-09-07 12:45 Slender Note Added: 0003611
2018-09-07 17:17 Saga Musix Note Added: 0003612
2018-09-07 17:18 Saga Musix Note Edited: 0003612 View Revisions
2018-09-07 18:06 manx Note Added: 0003613
2018-09-07 18:09 manx Note Added: 0003614
2018-09-07 18:10 Saga Musix Note Added: 0003615