Modtracker on Linux (!)[Reported to work @ page 2]

[Asharin]

But could it not be compiled against the WINE libraries making it more or less 100% compatible with WINE under linux?

Well... not exactly.

It doesn't actually help with Wine compatibility, so OpenMPT itself must first work perfectly under the respective Wine version before it can be built against the Wine development libs (formerly collectively known as winelib) of the same version, which are both derived from the same codebase.

The purpose of compiling it against the libs is to have it running natively on Linux, since doing so compiles the entire Win32 API into the program as if it were any other development toolkit, resulting in a self-contained, potentially Linux-runnable binary (although it would still depend on shared libraries and such).

Ahh I get you. Not being a coder I wasn't sure how that worked I don't mind compiling stuff under linux, but if a program isn't written in Pacal or forth or basic I don't have a clue, and considerign I haven't touched THOSE languages for close to 15 years now, even then I wouldn't be sure what I am doing anymore

[xaimus]

".wild.001" works well.  Aside from that, I cannot add any relevant information that has not already been stated.

[Randilyn]

Could we maybe get this thread stickied?  I think it's an important subject worth keeping track of,,,

[Randilyn]

I just tried FamiTracker on Wine 0.9.35 on Ubuntu Fiesty and it seems to have very similar problems.  Perhaps they have a common root cause ?

Note however that FamiTracker required audio emulation to even get the program started (otherwise it would throw a DirectSound error), and could be made to play songs (albeit very crappily) by using an very big buffer, such as 100ms or larger.  I thought I had tried this in OpenMPT as well, but with little to no success...

I can't remember. :x

[HvitRavn]

I want to note that MPTracker works perfectly fine in VMWare. I've tested (and used) it on both Feisty and Herdy Hoar (Nerdy Whore? Whaat?) or whatever the previous Ubuntu name was. Dunno about other distros though, but I assume it works fine as long as vmware works.

[pelya]

I want to note that MPTracker works perfectly fine in VMWare.

Of course it works! With VMWare you just creating another virtual computer in your computer, and run Windows inside it (and eats up all your system resources). So you need a Windows installation and also VMWare is cost some money. btw it will require some sound bufferization as well, so 10 ms lag will be always present.
Compiling ModPlug with WineLib sounds good until you want to use VST plugin. All VST plugins are compiled as Windows DLL files and require running Windows process to work (and there's no source code to compile with WineLib).
So the best option if you managed to run ModPlug .EXE using WINE emulator. The best thing programmers can do is to create native Linux output plugin for ModPlug running in Wine (could be tricky).

[HvitRavn]

Actually VMWare Server is gratis And the sound setup is just a matter of configuring vmware properly, and it works fine. I don't know what bufferization is though (;

[pelya]

Actually VMWare Server is gratis

Wow, I didn't know. Cool .

And the sound setup is just a matter of configuring vmware properly, and it works fine. I don't know what bufferization is though (;

Oops, have I spelled it incorrectly?
Do you run other software on your VMWare server?
Anyway WINE should be faster and eat less resources. However some bad-written VST plugins may glitch in WINE. So maybe just use VMWare (and put it into ModPlug distribution archive :wink: ).

[Randilyn]

Compiling ModPlug with WineLib sounds good until you want to use VST plugin. All VST plugins are compiled as Windows DLL files and require running Windows process to work (and there's no source code to compile with WineLib).

To be honest, I don't think VSTs are truly an issue here, as aside from being DLLs, they should not use the Win32 API, but a dedicated VST API (provided by the VST SDK) instead in order to remain compliant with all programs that can load them.  Said API could eventually be implemented using High Level Emulation (HLE).

So eventually, with some work you might be able to run VSTs if you just have an x86 processor.  But I'm not entirely sure on this as I don't know that much about VST internals.  However, in cases where the Win32 API is absolutely required, a consierable effort already exists to load and run Windows-specific VSTs in Linux.

But there are better  trackers out there for those kinds of things.  Let's only worry about the basic functionality in OpenMPT for now, okay folks?  And as I told the person who was mentioning Cedega - most of us aren't even interested in commercial solutions such as VMWare, as they essentially make OpenMPT non-free.

[Asharin]

And as I told the person who was mentioning Cedega - most of us aren't even interested in commercial solutions such as VMWare, as they essentially make OpenMPT non-free.

Oh quit harping on about that, I just mentioned it as a suggestion, if like, you already HAD cedega installed.
Personally I don't use Cedega these days, I just run games (and modplug, reaper etc) on a seperate windows pc.

[xaimus]

I just tried FamiTracker on Wine 0.9.35 on Ubuntu Fiesty and it seems to have very similar problems.  Perhaps they have a common root cause ?

Note however that FamiTracker required audio emulation to even get the program started (otherwise it would throw a DirectSound error), and could be made to play songs (albeit very crappily) by using an very big buffer, such as 100ms or larger.  I thought I had tried this in OpenMPT as well, but with little to no success...

I can't remember. :x

Indeed.  I had similar issues, but never succeeded in getting FamiTracker to output sound without stuttering horribly--though I did not need to enable audio emulation.  I have not had any luck at all in getting OpenMPT to output sound properly.

I started browsing through wine's source to see if I could figure out why the thread was timing out, but had no luck.  winedbg fails to run consistently on my computer; I am unsure if that is because of wine's half-hearted FreeBSD port or because winedbg is just broken.  I have a lot to learn about wine's internals.

edit: typos

[pelya]

I succeeded running OpenMPT v1.17.02.48 on Wine 0.9.41 on Kubuntu 7.04 Linux using both Wave Mapper and DirectSound output in OpenMPT settings.
Both have huge half-second audible click when you start or restart playing, but then plays fine. Also when you move mouse around GUI or click some GUI elements playback will skip/click a bit (that's on 3GHZ Pentium 4!) - increasing MPT buffer size to 100ms fixes that. Everything else seems to be fine, even plugins work (I tested MDA_BANDISTO/etc plugins from MPT Quick Starter kit).
Edit: You should get winhttp.dll and put in in the same folder with mptrack.exe. Or wait until next release where this dll will be optional .
I also sent update to Wine application database .
The bugfix obviously came from Wine side, 'cause there were no changes in MPT sound ouput engine AFAIK. That's nice, made bugfix without lifting a finger - thank you, Wine guys!

[cubaxd]

Everything works great with wine 0.9.41!
So, Goodbye forever, MPT 1.16, you've been a good fellow :-D
And thanks, pelya! Without you telling it i would have been waiting for another 2 years before trying it again ;-)

[pelya]

Right now I'm trying to tweak MPT sources to be compiled on Linux 'natively', so to say, with help of WineLib, I've already compiled MFC from VisualStudio 6 SP6 (with huge tweaks, of course) and made compilable 12 of 122 .CPP files of MPT sources. When I'm finished MPT should run A LITTLE faster than original .EXE run with Wine (if it will run at all in the end, that's it) - Wine will run in the background anyway, maybe GUI drawing will be faster.
So here's the question: doesn't that looks to you like waste of time (kinda 12/122 = 10% progress in a two days).
It probably cannot be released in sources, like everything in Linux is, because of MFC - if you want to compile MPT you should legally get a copy of VisualStudio 6, apply SP6 to it, rip out MFC, apply some very custom patch to it and only then you can compile. The same thing is with porting MPT to freely availabe compiler like gcc - not until MPT will use some other GUI library.

[dBlues]

Why not ditch MFC (platfom-specific, old and slow proprietary gui lib) and start using something like QT4 (multi-platform, open gui lib)?