Author Topic: 3.8 reports, queries and bugs  (Read 204232 times)

saga

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #625 on: 4 Jan '19 - 22:41 »
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

  • Administrator
  • Posts: 21741
Re: 3.8 reports, queries and bugs
« Reply #626 on: 7 Jan '19 - 15:38 »
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

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #627 on: 7 Jan '19 - 21:45 »
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.
« Last Edit: 7 Jan '19 - 22:10 by saga »

bauxite69

  • Posts: 57
Re: 3.8 reports, queries and bugs
« Reply #628 on: 8 Jan '19 - 04:18 »
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

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #629 on: 8 Jan '19 - 19:32 »
Right, then I guess the source for AdLib-only format is still there but just not being linked...

bauxite69

  • Posts: 57
Re: 3.8 reports, queries and bugs
« Reply #630 on: 8 Jan '19 - 20:43 »
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

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #631 on: 8 Jan '19 - 21:23 »
Quote
Would you like to use it ?
No thank you, I have my own plugin ;D (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

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #632 on: 28 Jan '19 - 22:36 »
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
« Last Edit: 28 Jan '19 - 22:43 by saga »

saga

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #633 on: 13 Feb '19 - 08:06 »
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

  • Administrator
  • Posts: 21741
Re: 3.8 reports, queries and bugs
« Reply #634 on: 15 Feb '19 - 12:27 »
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

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #635 on: 25 Feb '19 - 21:35 »
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.
« Last Edit: 25 Feb '19 - 22:25 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 21741
Re: 3.8 reports, queries and bugs
« Reply #636 on: 26 Feb '19 - 15:58 »
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

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #637 on: 26 Feb '19 - 18:28 »
Thanks for the quick fix, this works as intended now.

saga

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #638 on: 17 Mar '19 - 21:02 »
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

  • Administrator
  • Posts: 21741
Re: 3.8 reports, queries and bugs
« Reply #639 on: 19 Mar '19 - 18:01 »
Oops, here's an update to fix that:

   www.un4seen.com/stuff/xmplay.exe

saga

  • Posts: 2298
Re: 3.8 reports, queries and bugs
« Reply #640 on: 20 Mar '19 - 13:40 »
Thanks for the quick fix!

RiotRetroGaming

  • Posts: 3
Re: 3.8 reports, queries and bugs
« Reply #641 on: 8 Apr '19 - 21:21 »
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

  • Administrator
  • Posts: 21741
Re: 3.8 reports, queries and bugs
« Reply #642 on: 11 Apr '19 - 13:26 »
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

  • Posts: 3
Re: 3.8 reports, queries and bugs
« Reply #643 on: 27 Apr '19 - 00:00 »
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

  • Posts: 4
Re: 3.8 reports, queries and bugs
« Reply #644 on: 29 Apr '19 - 13:56 »
Quote
xmp-midi.log
What's that? For what purpose? When this feature was added? How to turn it off?

Ian @ un4seen

  • Administrator
  • Posts: 21741
Re: 3.8 reports, queries and bugs
« Reply #645 on: 29 Apr '19 - 14:37 »
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.