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

saga · « **Reply #25 on:** 2 Jan '14 - 16:01 »

Regarding the MT2 issue, it seems to be rather random which plugin takes the file for me.
Testing it using another worlds always makes in_mt2 handle the file if MT2 is specified as priority filetype. Using Andromeda.mt2, xmp-openmpt takes the file. But when removing xmp-openmpt, in_mt2 will also try handling the file. I say "try" because the file will remain silent just like in xmp-openmpt, most likely because it was made in a too recent version of MT2.

Ian @ un4seen · « **Reply #26 on:** 2 Jan '14 - 16:36 »

Quote from: piovrauz on 1 Jan '14 - 11:08

I can confirm somthing is wrong with mt2.
I've installed the winamp plugin, got some .mt2 (full package of the tracker), put priority on the WA plugin, but it doesn't decode them.
OpenMPT plugin still gets to decode them (well, I hear silence when they play ).
I would say it's something on the plugin side, or WA related, since it doesn't display config window too...

I'm not sure if it's that XMPlay does something it doesn't expect, but I've always found the Winamp MT2 plugin to be a bit dodgy, where it will often not generate any data on the first use of it. I suspect what's happening here is that the Winamp MT2 plugin is tried first when it has priority for the "mt2" filetype, but it doesn't generate any data so XMPlay goes on to try other plugins. If you try playing the MT2 file a 2nd time, does the Winamp plugin handle it then? Anyway, here's an XMPlay update for you to try, which will automatically ask the Winamp plugin to try again if it doesn't generate any data the 1st time...

www.un4seen.com/stuff/xmplay.exe

While looking into this, I found that the xmp-openmpt plugin would crash with some MT2 files. Here's an example troublesome file...

ftp.modland.com/pub/modules/Mad%20Tracker%202/Looza/streets.mt2

saga · « **Reply #27 on:** 2 Jan '14 - 16:47 »

Thanks, I'll look into it. The MT2 loader is old and rusty and requires some serious rewrite.

And indeed, the latest update seems to help with the MT2 plugin being used instead of xmp-openmpt.

Knurek · « **Reply #28 on:** 2 Jan '14 - 16:51 »

Quote from: Ian @ un4seen on 2 Jan '14 - 16:36

While looking into this, I found that the xmp-openmpt plugin would crash with some MT2 files. Here's an example troublesome file...

ftp.modland.com/pub/modules/Mad%20Tracker%202/Looza/streets.mt2

Ian, any chance you could backport xmp-openmpt pattern display tech? It shows all those fancy commands/samples/etc used and looks just lovely.

piovrauz · « **Reply #29 on:** 2 Jan '14 - 18:46 »

+1 for "porting" / "expanding" mod pattern display.

Knurek · « **Reply #30 on:** 2 Jan '14 - 21:28 »

I've noticed something while trying the patter display vis with various modules - Basehead's "the zen garden.s3m" has noticeable clicks roughly 0:35 in when compared to XMPlay's replayer.

My settings:
Samplerate: 48kHz
Interpolation: 8 tap
Volume ramping: default

I can prepare wavewrites of the section for you if you can't replicate, maybe it's just some combination of EQ+Rev I'm using...

saga · « **Reply #31 on:** 2 Jan '14 - 22:22 »

It's a known issue that is going to be resolved eventually but requires a lot of work to fix properly. FWIW, the clicks won't appear if you disable interpolation.

Lunar07 · « **Reply #32 on:** 3 Jan '14 - 18:22 »

saga - Every project has to have an outline and a purpose.
Regardless of whether you do it on your own time, for fun and for some other reason.
You have a real life. We all do.
This "it is too bad" from you gives openMPT a bad reputation.
Just because you do it for fun is no reason whatsoever for this attitude.
Things have to be done right.
Otherwise, do it ****on your time****

Right now, the issue is this: your plugin insists on playing MT2 files.
And you KNOW quite well that the major formats are INTEGRATED into xmplay.

This means that while someone was doing the coding **for fun** did not think that many formats are natively supported by XMPLAY. And there maybe other plugins out there like MadTracker dedicated plugin.

And all this just not to add a File Extension Selector/Deselector into Config.

Well, yes it is just too bad. I removed your plugin. I can actually live without it and without your attitude.

piovrauz · « **Reply #33 on:** 3 Jan '14 - 18:50 »

@Lunar07: if you want to see ppl with attitude, I can point you some irc mods. Saga? He doesn't even bite (me, at least for now).
Are you really expecting someone do something the way you like, even if there's no good reason in his eyes, for free. and using this tone on top of it?
Last time I checked you were using an OS you paid good money for, made by a company tha does not care about what their users want. Real life.
Btw: libopenmpt is a lib from a tracker, not just a plugin. I'd say the plugins are like bonus...
You don't like it? It's open source add patches, fork, code one yourself, whatever.

This said, I'll do what you aren't doing (trying the new rev of XMPlay that should deal with the issue with .mt2).
Just wait I eat something, okie?

Sajadi · « **Reply #34 on:** 3 Jan '14 - 21:00 »

Great Job, sounds nice

Now i look forward for being able to save settings too

saga · « **Reply #35 on:** 3 Jan '14 - 21:32 »

Quote from: Lunar07 on 3 Jan '14 - 18:22

Well, yes it is just too bad. I removed your plugin. I can actually live without it and without your attitude.

Got no problem with that at all. Maybe it will save us from feature requests about things that can already be done. Just because you think that something should be implemented in a way so that every plugin developer has to re-implement it on their own, that doesn't automatically mean that it's the better way. Because, frankly, it isn't. What Ian implement in XMPlay is much better than other player's approach where it's up to the plugins, and as we all learned now, it's all due to a quick in the MT2 plugin that it didn't work the way you hoped it to work, but the latest version of XMPlay already works around this quirk.

piovrauz · « **Reply #36 on:** 3 Jan '14 - 21:39 »

@ SaphirJD: with last rev (r3552 I think) you should be able to save settings, or at least it seems I can (just tried putting mon output).

@ saga: let it go, he won't get that the filetype priority is good as is, he just want a config for filetype to support in the plugins, and he doesn't realize that he basically wants every plugin developer to implement it like that, which means a lot of (now uneeded) work; Ian took care of it at the source, so what's the problem?

Oh, I said I'd do the tests. I forgot, doing them NOW.

Dotpitch · « **Reply #37 on:** 3 Jan '14 - 21:52 »

Lunar07, does Ians update work for you?

piovrauz · « **Reply #38 on:** 3 Jan '14 - 22:24 »

Feedback on "Ian Update":

I tried some .mt2 from the tracker package: one, namely "Eternal Engine - Another Worlds.mt2", plays with no issues (using the WA plugin).
Sadly most of them are silent in XMAPlay and WA too, and often crash XMPlay and WA, like "cg_mt2demo_3domo.mt2" and "XnmE-Nuclear_Secret" does.
+Also, playing those with xmp-openmpt doesn't crash XMPlay or WA, they just play silent.
So nothing really related to the xmp-openmpt plugin in the end. Probably some special features of the tracker aren't supported by its WA plugin.

Ah! 2 other things:
1) In the directory you have to make a sub-directory named in_mt2, and put there the contents of Madtraker\Extensions, the .mtx files. This will change the sound a bit.
2) I can't seem to open the config window of this plugin. Nor in XMPlay nor in WA. Bummer.

saga · « **Reply #39 on:** 3 Jan '14 - 22:29 »

Quote from: piovrauz on 3 Jan '14 - 22:24

So nothing really related to the xmp-openmpt plugin in the end. Probably some special features of the tracker aren't supported by its WA plugin.

The plugin is much older than the last version of MT2 and very unstable in general. It's not a big surprise. Besides, the plugin will most likely not support VST plugins, which will explain some of the silence, but not all. Basically, I'd guess that the plugin only supports MT2 files up to version 2.0 properly, based on its behaviour.

piovrauz · « **Reply #40 on:** 3 Jan '14 - 22:45 »

@saga, question: I'd like to ask for a feature to be added to the xmp-openmpt plugin,basically, I'd like it to "respect" the looping settings of XMPlay.
I suppose I need to use the bugtrack, but do you think it's feasible? Would it require some work from Ian too? How to synch those 2 "roads"?

saga · « **Reply #41 on:** 3 Jan '14 - 23:33 »

We're well aware of the deficiencies of the current loop behaviour, but libopenmpt isn't really compatible with XMPlay's loop concept so it requires more work.

piovrauz · « **Reply #42 on:** 4 Jan '14 - 08:41 »

mmmm, OK.
Should I ask for it as a new feature on the bugtracker (as a reminder) or leave it for a later time?

saga · « **Reply #43 on:** 4 Jan '14 - 13:31 »

As said, it's a known limitation. Having it on the issue tracker won't make us more aware or motivated.

piovrauz · « **Reply #44 on:** 4 Jan '14 - 13:46 »

Ah, you meant it like that. OK then, no need to add it to the tracker.

Sajadi · « **Reply #45 on:** 4 Jan '14 - 16:31 »

ok, now samplerate gets saved, but Volumne ramping still resets with each new track, no matter which settings you had set in that field.

manx · « **Reply #46 on:** 4 Jan '14 - 16:48 »

Quote from: SaphirJD on 4 Jan '14 - 16:31

ok, now samplerate gets saved, but Volumne ramping still resets with each new track, no matter which settings you had set in that field.

Thanks for noticing this. Just a stupid copy+paste bug. A new build will be available in a couple of minutes.

manx · « **Reply #47 on:** 4 Jan '14 - 17:35 »

Quote from: SaphirJD on 4 Jan '14 - 16:31

ok, now samplerate gets saved, but Volumne ramping still resets with each new track, no matter which settings you had set in that field.

Should be fixed in http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/libopenmpt-win32-r3556.7z.

Sajadi · « **Reply #48 on:** 5 Jan '14 - 14:24 »

Works now as it should, thanks for the great job

Looking forward for future improvements

Dhry · « **Reply #49 on:** 5 Jan '14 - 23:27 »

Excellent work, saga and manx.
Copying in a note from comments on the libopenmpt blog post, as requested by saga. I have my system font changed to Tahoma and looking at the plugin options I can only see the word "priority" in the priority filetypes field. Screenshot:

Which of course sent me on a wild goose chase entering numeric values into it instead of actual file extensions..

Not sure if this is something to be fixed in the plugin itself or something to do with the actual XMplay dialog itself.

Cheers
Dhry