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

Dotpitch

  • Posts: 2870
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #50 on: 6 Jan '14 - 06:14 »
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. ... Not sure if this is something to be fixed in the plugin itself or something to do with the actual XMplay dialog itself.
That's in XMPlay's dialog, not in the input plugin. What would be the right way to solve this for you? Enlarge the textfield a bit and so it happens to work for this font? Or force the default font on the dialog?

saga

  • Posts: 2164
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #51 on: 6 Jan '14 - 10:28 »
Since there's plenty of space left, and since Tahoma is his default font, naturally it would be better to just extend the text field by a few pixels.

Ian @ un4seen

  • Administrator
  • Posts: 20286
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #52 on: 6 Jan '14 - 16:14 »
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.

The size of the "Priority filetypes:" text area was automatically defined by Visual Studio (so was the "Supported filetypes:" text area which is fully visible in your screenshot). I don't think enlarging areas for specific fonts is the answer, as what if some other font comes along that requires even bigger areas? I don't think the contents of the options window should be affected by the Windows font settings anyway. To investigate, please confirm the Windows version and exact font settings (including size) that you're using to produce the problem.

Lunar07

  • Posts: 19
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #53 on: 7 Jan '14 - 17:49 »
Lunar07, does Ians update work for you?

I have not been online on the web in a while.  I am going to try it today.
Having said that, I'd like to clarify a point.
Programmers who have an eye to what a program is supposed to do AND what the users would find useful  in the interface are **very few**
I know this because I am a programmer.
So from my point of view it is not enough for the program to do what it is supposed to do.  It has to pass the Users' test.
Many programmers fail on that second count.  They work as though they are in an island.

I am going to try the new xmplay.  
But I discovered that I do not need the openmpt plugin without the file selector/deselector.
In the same way that I removed the ffmpeg video player plugin.

Because after all most of my work is with IT and MT2 files.
As for MT2 files.  The MT2 winamp plugin is older than the current version of MT.
But nothing major was added to MT since the plugin was published except one extra effect and VST instruments.
The plugin will run into difficulties if VST ins are used.
Other than that the Winamp plugin never gave any issues.
And IT playback is integrated into xmplay.
Finally, I do apologize for my attitude.
My thanks to all: saga, Ian, you and everyone for all your work.
« Last Edit: 7 Jan '14 - 17:53 by Lunar07 »

Ian @ un4seen

  • Administrator
  • Posts: 20286
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #54 on: 10 Jan '14 - 17:41 »
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

Just checking... is anyone still seeing MT2 files being played by the XMP-OPENMPT plugin when the IN_MT2 plugin is given priority for the "mt2" filetype with this XMPlay update, or can the update safely be officially released? :)

Dhry

  • Posts: 64
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #55 on: 10 Jan '14 - 17:54 »
Just checking... is anyone still seeing MT2 files being played by the XMP-OPENMPT plugin when the IN_MT2 plugin is given priority for the "mt2" filetype with this XMPlay update, or can the update safely be officially released? :)
I just flipped priorities a few times and it worked as expected. Works fine. in_mt2 definitely sounds better IMO though, probably because you can turn off interpolation..

Dhry

piovrauz

  • Posts: 967
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #56 on: 10 Jan '14 - 19:08 »
@Dhry: you can turn of finterpolation? you mean you managed toopen the config windows of the WA mt2 plugin in XMPlay?

Dhry

  • Posts: 64
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #57 on: 10 Jan '14 - 20:52 »
@Dhry: you can turn of finterpolation? you mean you managed toopen the config windows of the WA mt2 plugin in XMPlay?
I miswrote that. I meant that you can't turn it off in the OpenMPT plugin and that it's automatically off in in_mt2. Interpolation makes the sound muddier and duller IMO.

Dhry

saga

  • Posts: 2164
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #58 on: 10 Jan '14 - 21:08 »
Err, of course you can. Just select "1 tap (nearest)" for interpolation in the config dialog.

Dhry

  • Posts: 64
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #59 on: 10 Jan '14 - 21:10 »
Err, of course you can. Just select "1 tap (nearest)" for interpolation in the config dialog.
Done already. Does this still not constitute interpolation though? I would have expected a "none" option.

Dhry

saga

  • Posts: 2164
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #60 on: 10 Jan '14 - 21:12 »
We could call it "no interpolation" as well. Nearest-neighbour sampling is just another equivalent term for that. You cannot interpolate anything with just one tap, you need at least two (linear interpolation). :)

Dhry

  • Posts: 64
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #61 on: 10 Jan '14 - 21:57 »
We could call it "no interpolation" as well. Nearest-neighbour sampling is just another equivalent term for that. You cannot interpolate anything with just one tap, you need at least two (linear interpolation). :)
Oh. There are still some noticeable sound quality differences between the two, possibly not because of the interpolation then. I typically just listen to SID music anyway, only downloaded and installed the OpenMPT plugin after seeing the OpenMPT program itself (from the link in your sig!) and being reminded of the days when I used to write mods..

Dhry

saga

  • Posts: 2164
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #62 on: 10 Jan '14 - 22:33 »
Well, I have no idea what MT2 does internally, but generally the difference between various sampler implementations without any kind of interpolation should be insignificant (compare e.g. XMPlay's no interpolation mode and OpenMPT's, it should sound more or less the same). Maybe the MT2 plugin uses linear interpolation in fact, which is still a bit "fresher" with old low-quality samples than "better" interpolation algorithms but not quite as crispy as no interpolation at all. And as said before, OpenMPT's MT2 support is old and buggy and really needs to be rewritten, so there are many more little details which could result in this difference.

manx

  • Posts: 17
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #63 on: 12 Jan '14 - 12:33 »
xmp-openmpt 0.2.3566-beta2 is released, which basically contains the settings-related fixes discussed here, a MT2 loader crash fix and various DBM playback improvements.
http://lib.openmpt.org/files/libopenmpt/bin/libopenmpt-0.2.3566-beta2-bin-win32.7z

Sajadi

  • Posts: 36
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #64 on: 12 Jan '14 - 14:58 »
The plugin gets better and better, keep on continuing the awesome work on it :) Thanks for all the effort :)

Small additional information... Have experienced right now something strange.. after downloading from the amp dascene amiga music page the track guitar slinger i was not able to play the song properly with the plugin as i renamed it into Guitar slinger.mod - but it was played correctly without mistake with its original name out of the archive file: mod.guitar slinger

Some strange bug perhaps? :D
« Last Edit: 12 Jan '14 - 16:09 by SaphirJD »

Dhry

  • Posts: 64
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #65 on: 12 Jan '14 - 16:26 »
Thanks for the update!
There are some definite idiosyncracies in playback between openmpt and in_mt2. For example in this file, openmpt throws in a huge amount of volume at ~13 seconds in. in_mt2 plays it fine. It's really not too big of a deal for me as I play these files so infrequently, but just thought I'd point out that I agree with saga re: the playback code needing to be revisited. Thank you also for indicating "none" in the 1-tap interpolation dropdown row.  :)

The size of the "Priority filetypes:" text area was automatically defined by Visual Studio (so was the "Supported filetypes:" text area which is fully visible in your screenshot). I don't think enlarging areas for specific fonts is the answer, as what if some other font comes along that requires even bigger areas? I don't think the contents of the options window should be affected by the Windows font settings anyway. To investigate, please confirm the Windows version and exact font settings (including size) that you're using to produce the problem.
Ian, I'm using Tahoma 8-point font under Windows 7 Ultimate x64 SP1. The actual method to change the system dialog fonts is to edit the registry, specifically the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes key, and the MS Shell Dlg and MS Shell Dlg 2 string entries. Changing these back to the originals causes XMPlay's dialog text to display fine again. The font point size is not defined anywhere that I can see, just the font name itself.

Dhry

saga

  • Posts: 2164
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #66 on: 12 Jan '14 - 17:40 »
Thanks for the update!
There are some definite idiosyncracies in playback between openmpt and in_mt2. For example in this file, openmpt throws in a huge amount of volume at ~13 seconds in. in_mt2 plays it fine. It's really not too big of a deal for me as I play these files so infrequently, but just thought I'd point out that I agree with saga re: the playback code needing to be revisited. Thank you also for indicating "none" in the 1-tap interpolation dropdown row.  :)
Yeah, it seems like the current loader doesn't import the channel volume... Not sure whether it's worth hacking that into the existing loader or just waiting until I rewrite it completely anyway.

Edit: Fixed, just redownload the latest development version from the site.
« Last Edit: 12 Jan '14 - 20:12 by saga »

manx

  • Posts: 17
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #67 on: 12 Jan '14 - 18:06 »
Small additional information... Have experienced right now something strange.. after downloading from the amp dascene amiga music page the track guitar slinger i was not able to play the song properly with the plugin as i renamed it into Guitar slinger.mod - but it was played correctly without mistake with its original name out of the archive file: mod.guitar slinger

XMPlay decides which plugin to use by looking at the file extension. In the case of amiga-style extensions at the front of the filename (as in "mod.guitar slinger"), there is none (or at least, ".mod" is not the extension at the end). As xmp-openmpt cannot be prioritized here, xmplay falls back to using its internal mod player. If "mod" is in your priority file types settings for xmp-openmpt, the renamed file ("guitar slinger.mod") will be played back via xmp-openmpt (xmp-openmpt indicates this in the status lines of the main xmplay window "(via openmpt)"). This would explain differences depending on the filename.

However, from a quick check, I did not notice any obvious playback problems with guiter slinger in xmp-openmpt. So I'm not quite sure what the actual problem might be here.

Dhry

  • Posts: 64
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #68 on: 12 Jan '14 - 23:09 »
Edit: Fixed, just redownload the latest development version from the site.
Nice one. The volume issue is definitely gone now. Will need to set up some time to listen to a few more tracks; throwing stuff into boxes for the next couple of weeks as we'll be moving house soon.

Thanks Saga.

Dhry

Sajadi

  • Posts: 36
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #69 on: 26 Jan '14 - 02:27 »
Small additional information... Have experienced right now something strange.. after downloading from the amp dascene amiga music page the track guitar slinger i was not able to play the song properly with the plugin as i renamed it into Guitar slinger.mod - but it was played correctly without mistake with its original name out of the archive file: mod.guitar slinger

Sorry for the late answer. Downloaded again one of the latest builds and tried again, the problem scene in guitar singer is between 1 minute 7 and 1 minute and 12 seconds... Using the normal xmplay playing routine, the song plays normal. While on the openmpt plugin the song hangs during that time frame. Just compare it with your plugin and the normal xmplay routine.

Same i have also experienced with other mod files, trying again some in the next few days and report them here.

Edit: Another not 100% correct working file is Endless, also from Jogeir Liljedahl. Compare the music part at 4:30 minutes in playback between your plugin and the xmplay playing routine and same song at 7:06 - 7:20, yours is playing that parts slower then xmplay and the samples sound somewhat strange.

So... something bugs at least at Jogeir Liljedahl tunes, the question is what's the culprit :D
« Last Edit: 26 Jan '14 - 02:44 by SaphirJD »

saga

  • Posts: 2164
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #70 on: 26 Jan '14 - 14:16 »
Thanks for the detailed report, there seems to be a little issue with some ProTracker compatibility stuff (which was introduced to fix condom corruption by travolta) that somehow doesn't work as intended. Please try this updated version.
« Last Edit: 26 Jan '14 - 15:32 by saga »

Sajadi

  • Posts: 36
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #71 on: 26 Jan '14 - 16:17 »
Thanks, that is much better now :D Glad that i was able to help a bit in bug finding process :D

Jimmy Neutron

  • Posts: 473
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #72 on: 26 Jan '14 - 21:21 »
(which was introduced to fix condom corruption by travolta)

John Travolta corrupts condoms?

Sajadi

  • Posts: 36
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #73 on: 26 Jan '14 - 22:01 »
*LOL* That context of the words.. just priceless :D

saga

  • Posts: 2164
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #74 on: 26 Jan '14 - 23:44 »
John Travolta corrupts condoms?
Yeah, and we're trying to work around that.