Topic: 3.8 reports, queries and bugs

[Guest]

I'm not sure what's going on with the latest EXE, but any modules I play that it supports by default will say "buffering..." and then crash... I've just been using the normal 3.8.5 EXE ever since but I'm not sure what's causing that that issue. 

[winner]

I'm not sure what's going on with the latest EXE, but any modules I play that it supports by default will say "buffering..." and then crash... I've just been using the normal 3.8.5 EXE ever since but I'm not sure what's causing that that issue. 

I can confirm this behavior with version 3.8.5.12 when trying to play .mod files.

[Ian @ un4seen]

Oops! Been a few mishaps recently ... This one is when the output isn't set to 32-bit. Here's an update to fix it:

   www.un4seen.com/stuff/xmplay.exe

[Guest]

Works now, thanks for the fix!

[saga]

There is an issue with the portamento between two different instruments in this tune: https://modarchive.org/module.php?60896 (right in the second pattern)
Using PT1 mode fixes it, but I think the current behaviour doesn't make a lot of sense in either mode.

[Ian @ un4seen]

Here's an update to get that file sounding better in "normal" MOD mode:

   www.un4seen.com/stuff/xmplay.exe

The change is in what happens when an instrument is used without a note. Please let me know if you find that's now broken for other files in "normal" MOD mode.

[saga]

It seems like combining instrument swaps with arpeggios is now broken in PT1 mode: https://modarchive.org/index.php?request=view_by_moduleid&query=191419

[Ian @ un4seen]

The XMPlay 3.8.5 and 3.8.4 release versions seem to sound the same, so I guess the issue has been there a while, perhaps forever? From the note range used in the file, it doesn't look like it is actually meant to be played in PT1 mode? Still, I'll try to get it sounding closer to real PT1.

[saga]

Good point, it doesn't look like a ProTracker module. I mostly tried PT1 mode because the module uses Invert Loop, which requires PT1 mode in XMPlay. So in the end it looks more like XMPlay needs another way to enable EFx commands without enforcing PT1 limits... OpenMPT just supports them unconditionally, no matter which type of MOD file, and I'm not aware of any issues so far. Maybe XMPlay could enable EFx support by default as well?

[Ian @ un4seen]

Here's an update that enables the EFx effect in normal MOD mode too (still disabled in FT2 mode):

   www.un4seen.com/stuff/xmplay.exe

This update should also bring PT1 mode closer in accuracy, by having the arpeggio period/freq wraparound when that exceeds the limit, instead of capping it (like ST3 Amiga limits does).

[saga]

Yup, that both sounds good. Thanks for the fix!