Author Topic: xmp-openmpt: An XMPlay input plugin based on OpenMPT (Read 168420 times)

Jimmy Neutron · « **Reply #75 on:** 28 Jan '14 - 01:00 »

Yeah, and we're trying to work around that.

Phew! I'm glad to hear that.

deus-ex · « **Reply #76 on:** 28 Jan '14 - 16:42 »

Condoms must be secured from corruption at all cost.

manx · « **Reply #77 on:** 21 Feb '14 - 13:16 »

xmp-openmpt 0.2.3746-beta3 is released. http://lib.openmpt.org/files/libopenmpt/bin/libopenmpt-0.2.3746-beta3-bin-win32.7z.
Contains MOD and XM playback and loader improvements in some corner cases, fixes clicks in certain sample loops, and other assorted bug fixes.

tongub · « **Reply #78 on:** 20 Mar '14 - 03:51 »

hello. i love the work you've done with this plugin, it adds a lot of great formats to xmplay. i have one question though, are there any plans to update the handling of mmd3 files, as they don't seem to play accurately. thank you for any help you can give.

saga · « **Reply #79 on:** 20 Mar '14 - 10:52 »

I planned on replacing the MED loader with xmp's implementation, but it's a lot of tedious work.

manx · « **Reply #80 on:** 8 Nov '14 - 17:11 »

Seeing xmplay looping behaviour for plugins being discussed in the xmp-libxmp thread, I decided to chime in here.

Quote from: Ian @ un4seen on 8 Nov '14 - 14:42

Do you mean when looping? If so, you signify the end by delivering less data than requested in your Process function, and then XMPlay will call your SetPosition function to go back to the start. If you include XMPIN_FLAG_LOOP in the plugin's flags, then the XMPIN_POS_LOOP or XMPIN_POS_AUTOLOOP value will be used in the SetPosition function to request looping or auto-looping. In the auto-looping case, the function should only loop when a loop has been detected, and otherwise return -1. If the time of the loop start position is known, that should be returned, otherwise -2 can be returned to let the time run on.

@Ian: For libopenmpt/xmp-openmpt, the current XMPlay looping model seems to not fit at all. Libopenmpt needs to know a-priori (or while playing back) the desired looping behaviour. The reason being, libopenmpt does, in general, not stop playback right at the point when the module finishes, but instead fades out the song using some volume ramping in order to avoid clicks on song end. XMPlay currently can only notify xmp-openmpt that we actually want to loop the module after this fadeout has already hapened, but obviously this is too late for libopenmpt because we already transmitted the fadeout pcm data. Currently, we completely ignore the XMPlay looping and provide a looping setting in our plugin settings dialog.
We could avoid our own setting if XMPlay can provide either a call to the plugin that sets the desired looping behaviour (which could be done, for example, directly after loading a file and when the setting changes) OR a way to query the XMPlay looping settings. I'm not aware of a way to query the XMPlay settings directly (I might be missing something).
If there is no such way, can you add this or something equivalent to the plugin API? Another XMPIN_FLAG_something is probably also required in order to signal to XMPlay that the plugin uses a different looping model than the default.
The libopenmpt looping model supports "none"/"infinite"/"number of repeats as integer". Libopenmpt (currently) can not support the XMPlay-style auto-looping. However, for future extensibility, this setting could also be made available to plugins.
Querying other XMPlay settings would also be useful in general. We could potentially avoid our own interpolation and volume ramping settings. These are less important from my point of view, though.

saga · « **Reply #81 on:** 8 Nov '14 - 19:17 »

And while we're in Q&A mode...
I'm trying to get subsong support working in xmp-openmpt. I implemented GetSubSongs, which works fine as long as I just return the number of subsongs. I am not quite sure how to utilize the float* parameter - I tried writing the subsong lengths into it, but this leads to a crash. How is this parameter supposed to be used?
Edit: I looked at the xmp-asap code, and noticed that they simply add up the length of all sub songs into one floating point variable. However, the sub songs still do not turn up as individual entries in the general info window. Do I have to do that myself via GetGeneralInfo?

Ian @ un4seen · « **Reply #82 on:** 10 Nov '14 - 16:21 »

Quote from: manx on 8 Nov '14 - 17:11

@Ian: For libopenmpt/xmp-openmpt, the current XMPlay looping model seems to not fit at all. Libopenmpt needs to know a-priori (or while playing back) the desired looping behaviour. The reason being, libopenmpt does, in general, not stop playback right at the point when the module finishes, but instead fades out the song using some volume ramping in order to avoid clicks on song end. XMPlay currently can only notify xmp-openmpt that we actually want to loop the module after this fadeout has already hapened, but obviously this is too late for libopenmpt because we already transmitted the fadeout pcm data. Currently, we completely ignore the XMPlay looping and provide a looping setting in our plugin settings dialog.

That sounds like the XMPIN_FLAG_TAIL flag is what you want, in addition to the XMPIN_FLAG_LOOP flag. At the end, XMPlay will call the plugin's SetPosition function with XMPIN_POS_LOOP or XMPIN_POS_AUTOLOOP if looping is enabled. If looping isn't enabled (or the plugin rejects it), then the plugin's SetPosition function will be called with XMPIN_POS_TAIL if the "Wait for end to decay" option is enabled, to tell the plugin to play any decay/fadeout that it has. Like with looping requests, SetPosition can return -1 to signify that there is no tail.

If the plugin needs to know whether XMPlay will ask it to loop (eg. to decide whether to stop at a loop point or continue to the end), the plugin's Process function can call the XMPFUNC_IN GetLooping function. For example, if looping is limited to 1 time, then it will return TRUE before looping and then FALSE after looping once.

Quote from: manx on 8 Nov '14 - 17:11

Querying other XMPlay settings would also be useful in general. We could potentially avoid our own interpolation and volume ramping settings. These are less important from my point of view, though.

There isn't currently a reliable way to get that info. It could be read from XMPLAY.INI, but that doesn't get updated immediately when the settings are changed via the XMPlay window's controls or shortcuts. I guess your options may not be quite the same as XMPlay's anyway, so probably best to use your own settings (still stored in XMPLAY.INI via the XMPFUNC_REGISTRY functions) for this stuff.

Quote from: saga on 8 Nov '14 - 19:17

And while we're in Q&A mode...
I'm trying to get subsong support working in xmp-openmpt. I implemented GetSubSongs, which works fine as long as I just return the number of subsongs. I am not quite sure how to utilize the float* parameter - I tried writing the subsong lengths into it, but this leads to a crash. How is this parameter supposed to be used?
Edit: I looked at the xmp-asap code, and noticed that they simply add up the length of all sub songs into one floating point variable. However, the sub songs still do not turn up as individual entries in the general info window. Do I have to do that myself via GetGeneralInfo?

Yep, the plugin needs to add the subsong info to the General info window itself via GetGeneralInfo. Note that it shouldn't do that when in single/separated subsong mode (SetPosition called with XMPIN_POS_SUBSONG1). To fully support subsong separation, GetFileInfo should also provide subsong info, something like this...

Code: [Select]

DWORD WINAPI GetFileInfo(const char *filename, XMPFILE file, float **length, char **tags)
{
	// parse file here
	if (length) {
		float *lens=(float*)xmpfmisc->Alloc(songs*sizeof(float)); // allocate array for length(s)
		for (int a=0; a<songs; a++)
			lens[a]=songlength[a];
		*length=lens;
	}
	if (tags) {
		// get tags here
	}
	// free parsed stuff here
	return songs; // return number of subsongs (add XMPIN_INFO_NOSUBTAGS if there's a single set of tags for all subsongs)
}

And the SetPosition function could look something like this...

Code: [Select]

double WINAPI SetPosition(DWORD pos)
{
	if (pos==XMPIN_POS_TAIL) {
		// tail stuff
	} else if (pos==XMPIN_POS_LOOP) {
		// looping stuff
	} else if (pos==XMPIN_POS_AUTOLOOP) {
		// auto-looping stuff
	} else if (pos&XMPIN_POS_SUBSONG) {
		// subsong changing stuff
		subsong1=pos&XMPIN_POS_SUBSONG1; // single/separate subsong mode
	} else {
		// normal seeking stuff
	}
}

saga · « **Reply #83 on:** 10 Nov '14 - 17:57 »

Quote from: Ian @ un4seen on 10 Nov '14 - 16:21

There isn't currently a reliable way to get that info. It could be read from XMPLAY.INI, but that doesn't get updated immediately when the settings are changed via the XMPlay window's controls or shortcuts. I guess your options may not be quite the same as XMPlay's anyway, so probably best to use your own settings (still stored in XMPLAY.INI via the XMPFUNC_REGISTRY functions) for this stuff.

I think some options would be quite favorable to be shareable, e.g. interpolation or fade-out length settings (and maybe even the PT1.x flag for MOD files). That way, the user can use the same shortcuts without any hassle, and they don't have to think which plugin they are currently using.

manx · « **Reply #84 on:** 21 Dec '14 - 09:52 »

2014-12-21: xmp-openmpt version 0.2.4664-beta8 released!

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

Notable changes:

Subsong and hidden subsong support
Vastly improved MT2 loader
Improved playback compatibility for S3M files not made with ScreamTracker
libopenmpt_settings.dll is gone and .NET is no longer required for the configuration dialog

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

saga · « **Reply #85 on:** 21 Dec '14 - 13:21 »

Two more notable changes that finally turn XMPlay into a real replacement for the old ModPlug Player...

Independent pitch and tempo control! There are now four shortcuts in XMPlay that you can configure to control xmp-openmpt's playback tempo and playback pitch.

Now we're all waiting for the traditional christmas XMPlay release...

piovrauz · « **Reply #86 on:** 21 Dec '14 - 16:04 »

nice improvements, expecially the settings window now seems to opens faster.

deus-ex · « **Reply #87 on:** 6 Jan '15 - 18:34 »

Hi saga,

just noticed that the replay of fracture in space.stm is wrong. Probably sumting wong with panning?

saga · « **Reply #88 on:** 6 Jan '15 - 21:05 »

Okay, this is really nasty. I have observed some STM files in the past (ACIDLAMB.STM) that would only load correctly when omitting any zero-volume samples. However, in this particular file, this behaviour seems to corrupt the sample loading, hence everything sounds broken. I'll have to see what the *real* reason is that the samples in ACIDLAMB.STM mustn't be loaded then, I guess...
Edit: I guess I'll revert the code to using the 20-bit file offsets in the sample header, not sure why I stopped using them at some point.
Edit: An updated version of xmp-openmpt is now available at http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/

brycco · « **Reply #89 on:** 7 Mar '15 - 04:17 »

It won't load .OKTA (Oktalyzer) files from modland, they have to be renamed to .OKT.. seems a bit lame, considering files usually don't rely on file extension ! xmp-libxmp loads regardless of extension

saga · « **Reply #90 on:** 7 Mar '15 - 17:58 »

This is currently more or less an intentional restriction so that the plugin won't have to load each and every file completely into memory that potentially gets thrown at it (and that'd be any file that is being opened by a plugin that follows xmp-openmpt alphabetically and Winamp plugins). There's still some work left to do until this is not necessary anymore. (until then, #define FAST_CHECKFILE in xmp-openmpt.cpp can be removed to circumvent this)

Well, I took a shortcut to reduce the amount of work, so here's an updated version that doesn't need any file extension checking anymore and still doesn't require to examine the whole file (to clarify why this was actually necessary: just think of streams.):
http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/libopenmpt-win32-r4839.7z

captaincavern · « **Reply #91 on:** 10 Mar '15 - 17:39 »

I can't playback many Impulse Tracker modules with the standalone version (dunno if it applies to the plugins as well as I haven't checked). Those two for example:

http://lite.modarchive.org/index.php?query=idolatry.it&request=search&search_type=filename
http://lite.modarchive.org/index.php?query=pk_gloria.it&request=search&search_type=filename_or_songtitle

Been a little while I meant to post about it so it's not only with that last version.

Cheers.

saga · « **Reply #92 on:** 10 Mar '15 - 18:01 »

These files work just perfectly in OpenMPT 1.24, openmpt123 (both on Windows and Linux) and xmp-openmpt for me. What exactly is the issue you are experiencing?

captaincavern · « **Reply #93 on:** 11 Mar '15 - 00:26 »

I have no problems with them in OpenMPT, however they don't play in openmpt123, it just autoexits.

I am just checking out now if I get a message in the console and yes I get one and it says: errors loading 'idolatry.it' and error playing 'idolatry.it' : bad allocation. I am on Windows Me if that matters, I guess it does.

I encounter this problem only on some IT modules so far and those modules play fine in whatever else I tried them.

Now I have just noticed something else in case it might be related, on all the ITs that play OK I get a "PortAudio warning: Output underflowed" line above the L/R VU meters lines. I don't have this message with any other module types I have tried so far.

Edit: I also just checked xmp-openmpt and it doesn't appear I have that problem with it, the issue would appear to be limited to openmpt123 only.

manx · « **Reply #94 on:** 11 Mar '15 - 10:52 »

Quote from: captaincavern on 11 Mar '15 - 00:26

I am just checking out now if I get a message in the console and yes I get one and it says: errors loading 'idolatry.it' and error playing 'idolatry.it' : bad allocation.

Which version are you testing exactly? 4834 and 4835 had a bug which could result in enormous memory consumption and may very well lead to that problem. I can reproduce the problem with the affected versions on Windows XP. So updating will probably fix the problem for you. The latest versions are always available at http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/.

Quote from: captaincavern on 11 Mar '15 - 00:26

I am on Windows Me if that matters, I guess it does.

I'm even surprised anything works at all on Windows ME. That is not a supported platform with the compiler version we are using. Anyway, if it works in general, that alone should not make a difference in which files it can load or cannot load.

Quote from: captaincavern on 11 Mar '15 - 00:26

Now I have just noticed something else in case it might be related, on all the ITs that play OK I get a "PortAudio warning: Output underflowed" line above the L/R VU meters lines. I don't have this message with any other module types I have tried so far.

ITs in general require more processing power (due to filters, NNAs and possibly more channels).
Try increasing the buffer sizes and user interface update interval of openmpt123. i.e. openmpt123 --buffer 250 --period 50 --update 50 foobar.it. Disabling all console output of openmpt123 via --quiet might also help. Try playing around with the values. See openmpt123 --help for details.
If that does not help, your computer and/or Windows ME might just be too slow.

captaincavern · « **Reply #95 on:** 11 Mar '15 - 13:29 »

Quote from: manx on 11 Mar '15 - 10:52

Which version are you testing exactly? 4834 and 4835 had a bug which could result in enormous memory consumption and may very well lead to that problem. I can reproduce the problem with the affected versions on Windows XP. So updating will probably fix the problem for you. The latest versions are always available at http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/.

Thanks, it works fine with the latest version, I wasn't aware of that repository, bookmarked it!

Quote

I'm even surprised anything works at all on Windows ME. That is not a supported platform with the compiler version we are using.

That's because I have KernelEx and KernelEx extensions installed, this helps a lot with running newer programs, not everything unfortunately.

Quote

ITs in general require more processing power (due to filters, NNAs and possibly more channels).
Try increasing the buffer sizes and user interface update interval of openmpt123. i.e. openmpt123 --buffer 250 --period 50 --update 50 foobar.it. Disabling all console output of openmpt123 via --quiet might also help. Try playing around with the values. See openmpt123 --help for details.
If that does not help, your computer and/or Windows ME might just be too slow.

That message is gone too with the latest version, no need to do anything. Average CPU use for playing ITs with openmpt123 is about 3.5% on this machine btw

.

Thanks!

guest · « **Reply #96 on:** 29 Mar '15 - 14:28 »

669 modules aren't played properly with xmp-openmpt 0.2.4910

manx · « **Reply #97 on:** 29 Mar '15 - 16:30 »

Quote from: guest on 29 Mar '15 - 14:28

669 modules aren't played properly with xmp-openmpt 0.2.4910

Oops, thanks for the report.
Saga Musix has just fixed it in r4911.
Please try the updated version.

guest · « **Reply #98 on:** 12 Apr '15 - 17:16 »

ftp://modland.com/pub/modules/Protracker/Dreamer/black queen.mod
isn't played correctly.

saga · « **Reply #99 on:** 12 Apr '15 - 18:14 »

Seems like the loop detection was a bit too aggressive with nested pattern loops. r4928 fixes the issue and will be downloadable in a little while (~1 hour) from http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/

PS: Please be more specific than "not played correctly" next time - while it was somewhat obvious in this case, I'm not very much into guessing what doesn't work as intended (especially since I will usually check OpenMPT first and I know that OpenMPT plays Black Queen just fine).