xmp-openmpt: An XMPlay input plugin based on OpenMPT

Started by saga,

piovrauz

@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

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

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

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

piovrauz

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

Sajadi

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

Quote from: SaphirJDok, 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

Quote from: SaphirJDok, 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

Works now as it should, thanks for the great job :D Looking forward for future improvements :)

Dhry

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

Dotpitch

Quote from: DhryI 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

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

Quote from: DhryCopying 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

Quote from: DotpitchLunar07, 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.

Ian @ un4seen

Quote from: Ian @ un4seenI'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

Quote from: Ian @ un4seenJust 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

@Dhry: you can turn of finterpolation? you mean you managed toopen the config windows of the WA mt2 plugin in XMPlay?

Dhry

Quote from: piovrauz@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

Err, of course you can. Just select "1 tap (nearest)" for interpolation in the config dialog.

Dhry

Quote from: sagaErr, 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