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

[Relabsoluness]

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

In other words - why not rewrite most of the program from scratch? About those MFC properties, this is yet again one example that code performance related comments are one of the most inconsistent things that comes to mind - previous comments I remember about MFC is that its fast

[älskling]

why not rewrite most of the program from scratch?

great idea!  

[dBlues]

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

In other words - why not rewrite most of the program from scratch? About those MFC properties, this is yet again one example that code performance related comments are one of the most inconsistent things that comes to mind - previous comments I remember about MFC is that its fast

Okay, so too much work because GUI is too much rooted into the software. Lets fuggeddaboudit.

I am not a GUI-expert, that comment spawned from the mere thought of a proprietary ui-library... Jokes aside, I heard month ago that MFC is slow. That was due to formatting a folder-view. QT draws its own ui, and is platform-independent. But, I am not saying MPT is slow, on the contrary. Anyway, the really big advantage would be multiple platforms.

[Relabsoluness]

.

[pelya]

Okay, I've tweaked MPT sources from SVN rev.191 so they are compilable on my Kubuntu with help of Winelib - I cannot produce binary due to numerous link errors (and I don't think I'll can at all - there's too much to add to Winelib).
This may however be used as starting point to port MPT to gcc (at least soundlib).
The archive contains all the files to compile it on the same system as mine by just running "make" (link stage will fail) - it contains OpenMPT SVN tree (just deleted .EXE file), so you'll be able to run 'svn diff' and watch changes. Also it contains modified MFC sources from Visual Studio 6 SP6 (I've downloaded the original ones from Micro$oft site  :lol: quite outdated though ), and several tricky files for Winelib ( some of them from Win32 API - it publicly available anyway ).
PS. Soundlib will need some MFC classes like CString - it's easy to emulate CString with std::string - it's up to anyone wishing to continue that    I'm full of it already  :evil: .
PPS. Use 7-Zip to unpack .tar.bz2 on Windows  :wink: . Or download in ZIP - it's 2 mb bigger.
Edit: Okay, I've figured out the missed Wine libs and updated asm macros, planning to fix tomorrow.
Edit2: Yay, it compiles, links, generates 200Mb Linux binary, and crashes when you try to run it. The progress is noticeable  :wink: , however I won't debug or fix it  :evil: , 'cause I like it as it is (I just have no time). So, here's the archive ( or ZIP archive ). Don't forget to specify '-x --ignore-eol-style' option to 'svn diff'.
Edit3: The whole thing seems pointless now - who needs Linux binary which runs no faster than .EXE? I've installed MinGW with gcc-g++-4.2.1-sjlj-1.tar.gz2 package which runs on Windows and on Linux with Wine and produces .EXE file, and now I'm porting to it - it already compiles, but not links yet, however MFC test app works perfectly. The archive (or ZIP archive) contains "wrc" utility from Wine compiled by me for win32 - MinGW "windres" cannot handle modern .RC files.

[pelya]

Finally it compiles and works! .tar.bz archive, .ZIP archive ,   .DIFF file for SVN . To compile it download MinGW 5.1.3 (download net-install .EXE, select there only MAKE package and path to install "C:\MinGW" - it written in Makefile), gcc-core-4.2.1-sjlj-1 and gcc-g++-4.2.1-sjlj-1 (extract archives with 7-Zip into MinGW directory) . Then boldly go to "OpenMPT/mptrack" dir, squarely execute "mingw32-make debug" or "mingw32-make release" and pray for success   . The debug .EXE will be about 250Mb , and I didn't tested release :lol: .
Oh, the archive contains modified MFC lib from VS6, so you should be proud owner of Visual Studio 6 or above to legally download the archive . The next step is to get rid of MFC :wink: (however the amount of job is unrealistic    :cry: ).

[Relabsoluness]

The debug .EXE will be about 250Mb

250 Mb?

The next step is to get rid of MFC :wink: (however the amount of job is unrealistic    :cry: ).

One might have said that making OpenMPT compile on MinGW is unrealistic(even if using MFC)

[pelya]

The debug .EXE will be about 250Mb

250 Mb?

Stripped debug is only 4Mb, release packed with UPX is 1.2Mb . Visual Studio just puts all debug info in separate file, but it's about 100Mb too.
Okay, tests show that debug version will play about 5 seconds of audio and then crashes :oops: , and release doesn't crash, but all notes have wrong pitch :? (probably something with tunings, because the samples play fine).
Updated version: .ZIP .tar.bz2 .diff (release can now be built, run "mingw32-make release CPU=i686", some fixes in Makefile, sources almost not changed).
[Edit] The thread slowly shifted from original topic to "Modtracker on free compiler", maybe create different thread? However I've (almost) achieved what I wanted - compile/develop MPT on Linux, not just run.

[Relabsoluness]

...release doesn't crash, but all notes have wrong pitch :? (probably something with tunings, because the samples play fine).

Does it happen with all modtypes? The tuning handling is quite different when using the user definable tunings so it may give some indication where things go wrong if testing both.

[pelya]

...release doesn't crash, but all notes have wrong pitch :? (probably something with tunings, because the samples play fine).

Does it happen with all modtypes? The tuning handling is quite different when using the user definable tunings so it may give some indication where things go wrong if testing both.

I've tested only .IT files from Unreal Tournament. This happens even when I'm removing tuning files at all and MPT uses some defaults. The samples actually all played incorrectly too. And winedbg crashes when I'm trying to debug .exe, gdb from MinGW doesn't run with wine, and Microsoft debugger doesn't show me stack trace, because debugging symbols were generated by g++. So I'm giving up for now (maybe just install Windows in vmware?).
Edit: The .EXE generated with GCC-4.2.1 from MinGW package has wrong debug symbols attached, and old MinGW GCC has problems compiling MFC. I'll try to compile using older GCC (or maybe MinGW guys will update GCC faster - I've posted bug report already ).
Edit2: Ok, I've compiled MPT with GCC which came with MinGW by default - it generates correct debug info, but doesn't recognize some of Visual C++ pragmas and keywords, which seems to have no effect on output EXE. Debug version still crashes when trying to play, and now I'm debugging it with GDB in command line - I definitely don't wish such experience to anyone :cry: . I'll try to create Dev-Cpp project files to wrap that dreaded debugging command line into nice Dev-Cpp GUI   . Now both GDB for Windows and winedbg are working fine on MPT EXE, so theoretically I can develop without Windows at all   .

[pelya]

Okay, debug finally works as expected (release not tested). I've added Dev-Cpp project files - don't try to compile with Dev-Cpp though, just type "mingw32-make debug" from command line, and then debug with Dev-Cpp.
Finally I can implement something of real value to users (hey, maybe that was easier to copy VS2005 from home computer? Oh my, it already works).
So, the ZIP or .tar.bz file. If you try to compile this files ask any questions by ICQ. And if you never known the feeling of fear you may test the debug EXE file to report me how it works   .
Edit: Fixed a bug with assembler code (hoping the last one) and added VSTi Slave Mode. No .tar.bz, just ZIP this time . When run as VSTi Slave the debug version crashes on Windows but works on Wine, release seems to work everywhere.

[Relabsoluness]

Interesting quote from "Modplug Tutorial by Mister X a.k.a Kim, adapted by Kokki"(The 'date modified'-timestamp indicates that the tutorial file is from year 2000):

What do you need?
First of all: a computer with a decent soundcard. Although it's even possible to make music on a 386, it is recommended that you have a Pentium. Also note that the software is Microsoft Windows-based. (A Linux version is available at MODPlug Central.)

A Linux version?

[pelya]

Just updated VSTi
Edit:  diff file for VSTi without any MinGW stuff
 Fix for VST plugins with same identifier (all of JS plugins are reported to have the same ID) - just diff file

[Saga Musix]

I just tried to run  OpenMPT .48 in Wine 0.9.46 / Ubuntu 7.10. OpenMPT starts, but the main window just stais for a  couple of seconds and then closes. Any ideas what is going wrong here?

Edit: Before showing the OpenMPT main window, two message boxes appear "Can't open keyboard config file  Z:\home\jojo\default.,mkb for reading" and then there's the messagebox that i have to look for a keyboard file myself. This even appears after deleting the mptrack.ini file; default.mkb is in the OpenMPT folder.

[pelya]

I just tried to run  OpenMPT .48 in Wine 0.9.46 / Ubuntu 7.10. OpenMPT starts, but the main window just stais for a  couple of seconds and then closes. Any ideas what is going wrong here?

Edit: Before showing the OpenMPT main window, two message boxes appear "Can't open keyboard config file  Z:\home\jojo\default.,mkb for reading" and then there's the messagebox that i have to look for a keyboard file myself. This even appears after deleting the mptrack.ini file; default.mkb is in the OpenMPT folder.

Probably you have Wine configured wrong. Try running "wineconfig" and tweak some options. Most probably it cannot find "default.mkb" file - put it into your home dir, maybe edit your mptrack.ini - remove path from string "Key_Config_File=default.mkb", just leave the file.
Does the path really contain the comma? Something weird here.