Topic: 3.8 reports, queries and bugs

[saga]

Given that there are now at least two input plugins for XMPlay (based on libxmp and libopenmpt respectively) that support S3M files with both samples and FM instruments, would it be feasible to automatically use one of those plugins rather than the internal S3M decoder if any AdLib instruments (sample type = 2) are found an S3M file and one of the two plugins is installed? I know this issue could also be partially solved with priority file types (and making up a file extension such as AS3M as found on ModLand), but for that you first have to know that a file uses FM instruments before you can rename it.

[Ian @ un4seen]

Here's an update that adds a "Don't use built-in decoder on Adlib S3M files" option (so that a plugin can handle them instead) to the MOD options page:

   www.un4seen.com/stuff/xmplay.exe

[saga]

Thanks, works as advertised - and apparently the xmp-libxmp plugin doesn't actually have AdLib support enabled... I remember there are plans to remove OPL support from a future libxmp version but I guess currently it's just a matter of properly configuring the library.

[bauxite69]

Thanks, works as advertised - and apparently the xmp-libxmp plugin doesn't actually have AdLib support enabled... I remember there are plans to remove OPL support from a future libxmp version but I guess currently it's just a matter of properly configuring the library.

Claudio Matsuoka removed synth chip and Adlib emulation support from libxmp since version 4.4.0

https://sourceforge.net/projects/xmp/files/libxmp/4.4.0/Changelog/view

[saga]

Right, then I guess the source for AdLib-only format is still there but just not being linked...

[bauxite69]

Right, then I guess the source for AdLib-only format is still there but just not being linked...

Would you like to use it ?
I could add an option to toggle support for AdLib-only format ? BUT it doesn't sound very good 

[saga]

Would you like to use it ?

No thank you, I have my own plugin (and I use AdPlug for the stuff OpenMPT doesn't cover) - But if it can still be enabled without too much effort, I'd say add a toggle for it, the more plugins, the merrier! I'm sure someone can make use of it.

[saga]

When working on the differences "ModPlug mode" in MO3 issue, I noticed a peculiarity in Old Effects mode: As you observed, an instrument number next to a note-off also retriggers the envelopes, but if the instrument number next to the note-off is different from the previous instrument, the new instrument's envelopes and default sample settings (default volume, panning but not global volume) are used while the old sample keeps playing. I think that's the first time I have ever observed such an instrument/sample inconsistency in IT!
A test case for this weird behaviour can be found here: https://wiki.openmpt.org/Development:_Test_Cases/IT#ResetEnvNoteOffOldFx.it

[saga]

Recent changes in the MOD "normal" playback mode seem to have introduced some unwanted changes:
https://modarchive.org/index.php?request=view_by_moduleid&query=48953
At around 52 seconds in, you hear hear lead instrument constantly being retriggered even though it is just supposed to continue to play. In PT1 mode this does not happen, and I don't think it is supposed to happen in any other mode either.

[Ian @ un4seen]

When working on the differences "ModPlug mode" in MO3 issue, I noticed a peculiarity in Old Effects mode: As you observed, an instrument number next to a note-off also retriggers the envelopes, but if the instrument number next to the note-off is different from the previous instrument, the new instrument's envelopes and default sample settings (default volume, panning but not global volume) are used while the old sample keeps playing. I think that's the first time I have ever observed such an instrument/sample inconsistency in IT!
A test case for this weird behaviour can be found here: https://wiki.openmpt.org/Development:_Test_Cases/IT#ResetEnvNoteOffOldFx.it

Oh yes, it looks like global volume shouldn't be reset in that case. Here's an XMPlay update that should handle it correctly:

   www.un4seen.com/stuff/xmplay.exe

Recent changes in the MOD "normal" playback mode seem to have introduced some unwanted changes:
https://modarchive.org/index.php?request=view_by_moduleid&query=48953
At around 52 seconds in, you hear hear lead instrument constantly being retriggered even though it is just supposed to continue to play. In PT1 mode this does not happen, and I don't think it is supposed to happen in any other mode either.

The "normal" MOD mode is tweaked a bit more (only retrig if the instrument number changes) in the update above. Let me know if you notice any more strangeness with it.

[saga]

I have noticed a peculiarity in XMPlay's loop logic together with xmp-openmpt, I'm not sure yet if it's an XMPlay or plugin problem, so I'd appreciate your input.

Consider the attached MPTM file. If you add it to the XMPlay playlist (be sure that MPTM is in the priority filetypes for xmp-openmpt) and then double-click it to start playing, the module will loop and fade out (loop settings set to "never" and 5 seconds fadeout, also looping set to "never" in xmp-openmpt which should be called auto looping actually...). However, if I first play another file and queue the exampel file up, it will only play once (as intended), without any fadeout. I notice that the plugin's SetPosition is called with XMPIN_POS_AUTOLOOP in the case where the file is played by double-clicking, but not when it is played after another file finished playing.

[Ian @ un4seen]

I think the issue there is that the MPTM file does actually have a short gap at the end, and if the final output block happens to contain only that gap then XMPlay won't fade-out. It is the level of the final block (along with the plugin's loop detection if it has XMPIN_FLAG_LOOP set or the "Auto-loop any track ending with sound" option is enabled if not) that determines whether a fade-out can happen. Different output systems may use different block sizes, so you may get a different result if you change output system.

Here's an update that will only consider the level of the final 10ms, so there should be the same results regardless of output system:

   www.un4seen.com/stuff/xmplay.exe

[saga]

Thanks for the quick fix, this works as intended now.

[saga]

When MPT introduced stereo samples way back, it followed the principle for loop points to store them as bytes rather than frames, so just like with 16-bit samples the loop start and length have to be divided by 2 (so in the case of 16-bit stereo samples the loop points are divided by 4). The attached module should loop on the number 2, but it loops on the number 1 instead.

[Ian @ un4seen]

Oops, here's an update to fix that:

   www.un4seen.com/stuff/xmplay.exe

[saga]

Thanks for the quick fix!

[RiotRetroGaming]

Hi all.

Anybody else get this issue:
https://www.dropbox.com/s/gsgk41dt0r98ydi/8%20Apr%2C%2015.46.mp3?dl=0

The song is playing ok and will do this randomly over the top.
If I restart XM then it is fine... odd?

Is there any other 'newer' updste that fixes this or s workaround?

- just a quick addition... even if there is no internet stream filled out in the address box, if you tick 'auto-reconnect' there seems to be a random crash every now and then... it's taken me ages to figure out why I was getting this. See if you can replicate this too.

Thanks,
Ant

[Ian @ un4seen]

Anybody else get this issue:
https://www.dropbox.com/s/gsgk41dt0r98ydi/8%20Apr%2C%2015.46.mp3?dl=0

The song is playing ok and will do this randomly over the top.
If I restart XM then it is fine... odd?

Is there any other 'newer' updste that fixes this or s workaround?

That sounds strange. Not really sure what could be causing it except perhaps file corruption. Does it happen when playing a particular file, or file format? If a particular file, please upload it here:

   ftp.un4seen.com/incoming/

If you have any DSP plugins enabled, try disabling them to check if they're causing it.

Regarding updates, the latest one can always be found at this URL:

   www.un4seen.com/stuff/xmplay.exe

- just a quick addition... even if there is no internet stream filled out in the address box, if you tick 'auto-reconnect' there seems to be a random crash every now and then... it's taken me ages to figure out why I was getting this. See if you can replicate this too.

Ticking the "auto-reconnect" box doesn't really do anything at that time; it only comes into play when an internet stream connection dies. Did the crash happen exactly when you ticked the box or sometime after?

[RiotRetroGaming]

I updated the EXE, still the same.
It looks like it might be DELIX? When it says MED as the format... sometime after that noise appears it plays every sample in that song in uniform order over the song that's playing.

Weird, I'll have to contact the Delix guys.

[yoba]

xmp-midi.log

What's that? For what purpose? When this feature was added? How to turn it off?

[Ian @ un4seen]

Oops! It looks like debug logging was accidentally left enabled in the current MIDI plugin release. An update (rev.16a) to fix that is up now on the XMPlay page, so please re-download to get that.

[RiotRetroGaming]

This was fixed by removing DELIX and using the LibXMP plugin instead.... thanks.

[saga]

When encountering an S7x command in an IT file that stops an envelope (S77/S79/S7B), XMPlay seems to apply the value of that envelope which would have appeared on the first tick of that row. Impulse Tracker however keeps playing the envelope's value from the last tick of the previous row.

In the provided example, XMPlay pitches down the first note (it should play a constant pitch) and reduces the volume of the second note (it should stay at maximum volume).

[Ian @ un4seen]

Here's an update for you to try:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you find it's broken the envelopes in other IT files

[saga]

I went through my S7x-related tests and indeed found something that's broken, not sure if it used to work before this fix.
It's this test: https://wiki.openmpt.org/Development:_Test_Cases/IT#s77.it