▲

[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.