Topic: xmp-openmpt: An XMPlay input plugin based on OpenMPT

[guest]

Displayed duration is 1:46 but "black queen" module lasts 1:56

[saga]

Yes, that's part of the pattern loop trickery it does. The exact duration of nested pattern loops is complicated to compute (actually it's impossible to compute it correctly in every case because it may last forever), hence this is not going to be fixed.

[guest]

ftp://modland.com/pub/modules/OctaMED MMD0/Dr. Awesome/stardance.mmd0
Plugin plays only clicks at 0:00-0:06 and many sounds then in module aren't played.

[saga]

OctaMED support is known to be buggy and will be rewritten at some point, but don't ask me when that point will be. xmp or - even better - delix should be used for MED files.
Regarding that particular file - I didn't have a very close look but it seems like the "clicking" samples are synthesized instruments, which OpenMPT does not have support for at all.

[saga]

2015-04-18: xmp-openmpt version 0.2.4943-beta11 released!

Get it at http://lib.openmpt.org/files/libopenmpt/bin/libopenmpt-0.2.4943-beta11-bin-win32.7z.

Notable changes (most of them have already been discussed in this thread):

• Support for PLM (Disorder Tracker 2) files.
• Various playback improvements and fixes for IT, S3M, XM, MOD, PTM and 669 files.

xmp-openmpt website: http://lib.openmpt.org/

[guest]

Plugin doesn't play some arpeggios on channel 2 in
ftp://modland.com/pub/modules/Protracker/Arios/mr gang !!!.mod

[saga]

2015-04-19: xmp-openmpt version 0.2.4954-beta12 released!

Get it at http://lib.openmpt.org/files/libopenmpt/bin/libopenmpt-0.2.4954-beta12-bin-win32.7z.

We had do release a quick bugfix release for OpenMPT, we decided to make another official libopenmpt + input plugins release alongside. Among other tiny IT-related fixes, the module linked in the previous post now plays correctly.

xmp-openmpt website: http://lib.openmpt.org/

[deus-ex]

I just noticed that the download folder ../libopenmpt-win64/newer_versions_here/ stores the same archives as ../libopenmpt-win32/newer_versions_here/. Hence starting with release 5081 there are no 64-bit versions of the player application available anymore. Is that intended?

[manx]

I just noticed that the download folder ../libopenmpt-win64/newer_versions_here/ stores the same archives as ../libopenmpt-win32/newer_versions_here/. Hence starting with release 5081 there are no 64-bit versions of the player application available anymore. Is that intended?

Yes, that change was intentional in order to simplify things and to avoid wasting disk space. Do you see any actual advantage of a 64bit openmpt123.exe compared to the 32bit version?
I could add it back of course.
The canonical location is http://buildbot.openmpt.org/builds/ and the current link for libopenmt binaries is http://buildbot.openmpt.org/builds/auto/libopenmpt-win/ (subject to change).

[deus-ex]

Do you see any actual advantage of a 64bit openmpt123.exe compared to the 32bit version?

No, I don't have any argument supporting the requirement of the 64-bit builds of the player if there is no real advantage in terms of speed, stability or the ability to load certain modules and/or samples with respect to their file size. Then again, is there any valid argument for the 64-bit edition of the tracker? I'm not complaining, just asking.

[saga]

Then again, is there any valid argument for the 64-bit edition of the tracker? I'm not complaining, just asking.

While in general the tracker can make use of the whole address space for e.g. its sample undo buffer, the most important advantage is native support of 64-bit VST plugins, especially huge sample library players which many people use. With many e.g. orchestral samplers, you can quickly reach the 4GB limit.

[saga]

2015-09-13: xmp-openmpt version 0.2.5602-beta14 released!

Since beta13 (which I forgot to announce here, sorry!), this plugin comes in two flavours:
xmp-openmpt for CPUs with SSE2 instruction set - that's pretty much any x86 CPU made in the last ten years. Any 64-bit CPU automatically supports this.
xmp-openmpt for old CPUs without SSE2 instruction set

This (and the previous release) includes several bugfixes for crashes and hangs with malformed module files, several playback improvements for MOD, OKT, IT, XM, S3M and support for the latest new features in the MPTM format.

xmp-openmpt website: http://lib.openmpt.org/

[Dhry]

Awesome work, thank you!

[saga]

2015-10-31: xmp-openmpt version 0.2.5705-beta15 released!

This is just a minor update, bringing a few playback improvements.

xmp-openmpt for CPUs with SSE2 instruction set - that's pretty much any x86 CPU made in the last ten years. Any 64-bit CPU automatically supports this.
xmp-openmpt for old CPUs without SSE2 instruction set

xmp-openmpt website: http://lib.openmpt.org/

[saga]

2016-05-21: xmp-openmpt version 0.2.6401-beta17 released!

After half a year of silence, here's a rather big update:
- Built-in support for MO3 files (not really relevant for XMPlay, of course...).
- Support for DMO plugins in IT / XM / MPTM files.
- Support for the DigiBooster Pro Echo DSP in DBM files.
- Support for SoundFX / MultiMedia Sound (SFX / SFX2 / MMS) modules.
- Improved Ultimate SoundTracker version detection heuristics to fix playback of some UST modules.
- More fine-grained internal legacy module compatibility settings to correctly play back modules made with older versions of OpenMPT and a few other trackers.
- The tail of compressed MDL samples was slightly off.
- Some probably hex-edited XM files (e.g. cybernostra weekend.xm) were not loaded correctly.
- Countless other playback fixes for MOD, XM, S3M, IT and MT2 files.

Enjoy!

xmp-openmpt for CPUs with SSE2 instruction set - that's pretty much any x86 CPU made in the last ten years. Any 64-bit CPU automatically supports this.
xmp-openmpt for old CPUs without SSE2 instruction set

xmp-openmpt website: https://lib.openmpt.org/

[guest]

So xmp-openmpt save settings to the registry and not in xmplay.ini? 

[deus-ex]

Hi saga,

thanks for a very nice new release of OpenMPT/LibOpenMPT. Its development is steady and you never seem to run dry of adding new features, refinements and discovering/eliminating new bugs.

Speaking of bugs, I think I found one regarding the DigiTrakker format (.mdl). Playing back beyond all cognitive.mdl the module doesn't progress beyond the first order which is looped endlessly instead.

So xmp-openmpt save settings to the registry and not in xmplay.ini?

This makes me wonder, too. Why doesn't your plugin save it's settings to xmplay.ini like every other plugin usually does? Same question is true for the Winamp edition In_OpenMPT.dll.

[manx]

So xmp-openmpt save settings to the registry and not in xmplay.ini?

This makes me wonder, too. Why doesn't your plugin save it's settings to xmplay.ini like every other plugin usually does?

No particular reason short of "noone implemented that yet". The historical reason is that we did quite an implementation dance (calling a .NET DLL in earlier versions) with the settings window and it would have been rather convoluted to call the XMPlay settings functions from within that code. That's not the case anymore and I think there is no reason why we should not be using xmplay.ini. I'll implement that.

Same question is true for the Winamp edition In_OpenMPT.dll.

Winamp situation is quite different. We are only using Winamp 2 API which does not provide a way to store configuration in a Winamp-dictated way, as far as I know. There are quite a few lesser popular players that can deal with Winamp 2 style plugins but not with later ones.

[saga]

Speaking of bugs, I think I found one regarding the DigiTrakker format (.mdl). Playing back beyond all cognitive.mdl the module doesn't progress beyond the first order which is looped endlessly instead.

Haha, it does actually import the full order list but every pattern gets filled with the content of the first pattern for some reason. A complete rewrite of the MDL loader is in order anyway, but I'll see if I can fix it before the new loader is ready.

[manx]

So xmp-openmpt save settings to the registry and not in xmplay.ini?

This makes me wonder, too. Why doesn't your plugin save it's settings to xmplay.ini like every other plugin usually does?

No particular reason short of "noone implemented that yet". The historical reason is that we did quite an implementation dance (calling a .NET DLL in earlier versions) with the settings window and it would have been rather convoluted to call the XMPlay settings functions from within that code. That's not the case anymore and I think there is no reason why we should not be using xmplay.ini. I'll implement that.

From r6423 on, xmp-openmpt is now using xmplay.ini to store its settings.

[saga]

r6424 fixes the MDL issue (all MDL files except version 0 files were actually affected).
You will be able to download this version (which also contains the xmplay.ini fix) in about half an hour from now at the usual place: https://buildbot.openmpt.org/builds/auto/libopenmpt-win/

[deus-ex]

Hello manx and saga,

thank you both for your prompt response and great support, it's very much appreciated.

[deus-ex]

Winamp situation is quite different. We are only using Winamp 2 API which does not provide a way to store configuration in a Winamp-dictated way, as far as I know.

Suggestion: You could store the settings in a separate ini-file located in the folder of the plugin. I have seen a couple plugins using this method. That would, at least to some degree, provide a consistent strategy among your plugins.

I just checked your recent releases of the plugins, and I confirm that now all orders of beyond all cognitive.mdl are played. However the recreation of the 'Guitar', that starts at Order 10 on Channels 7 - 9, is quite off. My reference is the original DigiTrakker v3.2, executed in a DOSBox.

Based on my recent reviews of the plugins I'd like to give you some remarks:

• Winamp:
• Full credits cannot be scrolled, and they don't fit on screen even on my 3840x2160 display. Do we have to upgrade to 8K monitors? :D
• No dynamic information provided about current order, row, used channels/total used channels. Would be very nice to have.
   
• XMPlay:
• Same items as above.
   
• Foobar2000:
• No full credits option available. Forgotten?
• No dynamic information provided about current order, row, used channels/total used channels.
• No regular config dialog available, one has to resort to the (hidden) advanced settings, which I find rather inconvenient.
• No file extension management available. For example foo_GEP (Game Emu Player) by Kode54 does provide this in its config dialog. Screenshot: http://i.imgur.com/WOtxRsd.png

BTW: The installers of the stable OpenMPT release v1.26.02.00 both contain unmo3.dll, yet the changelog states the external library is not required anymore due to built-in support of the .mo3 format. Just sayin'. ;)

[saga]

I just checked your recent releases of the plugins, and I confirm that now all orders of beyond all cognitive.mdl are played. However the recreation of the 'Guitar', that starts at Order 10 on Channels 7 - 9, is quite off. My reference is the original DigiTrakker v3.2, executed in a DOSBox.

I'll look into it. It's probably something that will be automatically fixed by the new loader.
Edit: I suppose you are referring to the vibrato effect?

BTW: The installers of the stable OpenMPT release v1.26.02.00 both contain unmo3.dll, yet the changelog states the external library is not required anymore due to built-in support of the .mo3 format. Just sayin'.

Well, there's always the small print. unmo3 is not required on most setups, but under the following circumstances it is still used:
- Win32 / Win64 installation on Windows Server editions, because they typically do not have MediaFoundation installed
- Win32old is for systems with no MediaFoundation support anyway.
- MediaFoundation is not available in Wine.
In these three cases, mpg123 can be used as a fallback for MP3 sample decoding, but we cannot legally ship that without paying MP3 licensing fees, of course. Hence we just let unmo3 do the work in those three cases, unless the user manually installs mpg123.
I want to keep the changelog short and tidy (it's already long enough as it is), so I didn't go into further detail there. I hope this post clears up the confusion.

[manx]

Full credits cannot be scrolled, and they don't fit on screen even on my 3840x2160 display. Do we have to upgrade to 8K monitors?

Fixed in r6425.