Hello,
Are there any plans to port this tracker software?
Thanks!
At least I haven't heard that such would be under serious planning, but indeed it would be nice if OMPT was free from unnecessary platform dependencies.
I was wondering....
In order to compile the source properly, VS 2003 or 2005 .net is required. Doesn't that make it bound to a windows platform?
Quote from: "LPChip"In order to compile the source properly, VS 2003 or 2005 .net is required. Doesn't that make it bound to a windows platform?
When speaking about the current code, in practice it does, but parts that are VS-dependent can, of course, be rewritten(GUI in particular), but it won't be a small task - else it would likely have been done already.
But could it not be compiled against the WINE libraries making it more or less 100% compatible with WINE under linux?
OpenMPT does not work under Linux even under Wine. It has a sound output bug that hangs Wine (even on the latest versions). This bug is not present in the original ModPlug, only OpenMPT, so at least the developer(s) have a reference point to look for the problem.
And yes, I have tried all possible configurations for both Wine and OpenMPT (read: I know what I'm doing) - it will not work, and is even listed as having crippling sound bugs on the Wine website, whereas the original ModPlug is listed as working, albeit with a few VST issues that depends on the plugin being used.
Aside from that, it works 100%, the GUI and everything, and most VSTs. But that one sound output bug makes it nearly completely useless, unfortunately. :(
Screenshot of the GUI with desktop integration (using Wine 0.9.34 on Kubuntu Dapper Drake):
(http://img86.imageshack.us/img86/636/snapshot8gp9.th.jpg) (http://img86.imageshack.us/my.php?image=snapshot8gp9.jpg)
If the sound output bug(s) were fixed I would be willing to help design a new build system and get OpenMPT compiling against the Wine libraries (which provide the Win32 API, DirectX API, etc. directly into the program at compile time) and get the whole thing running natively on Linux.
Until then, I am also willing to help test any potential fixes to the sound output bug(s).
Does anyone have experience at what point things got broken? I remember hearing that some 'wild'-versions would work in wine, but apparently not RC1 anymore. Well if someone feels like spending time on figuring this out, old executables are available at http://modplug.cvs.sourceforge.net/modplug/wild/mptrack/bin/mptrack.exe?view=log
If anyone is interested in helping me to get this going, you can find me in #modplug on EFnet nearly 24/7 (except when I'm asleep, of course ;p).
Quote from: "Relabsoluness"Does anyone have experience at what point things got broken?
I've tested all wild versions with standard settings
Environment: Debian GNU/Linux 4.0, wine 0.9.35, Audio: OSS
The behaviour is everywhere the same:
After trying to play a sample or a mod, the first few milliseconds are played over and over again.
All actions which not use sound output can be done in that time. Program freezes completely after trying to push the pause or stop button
or trying to do any other action which has directly to do with the sound output.
the only error output of wine is:
err:ntdll:RtlpWaitForCriticalSection section 0x7ebcdcc8 "winmm.c: WINE_MM_IDATA.cs" wait timed out in thread 000c, blocked by 000f, retrying (60 sec)But i tested it only with the standard settings of wine.
With OMPT 1.17.2.28 i tried various different settings without any success.
I know modplug works fine with Cedega, a WINE derivative, but eh, you have to pay for that, though not neccesarily a lot, it has a lot of commercial code in now I belive, what I did was just subscribe for 1 month a while back to get the latest version.
If there's a new version out I occasionally sub for another month just to get the new version :D Not so often now though as my linux box has been in pieces for a couple fo months, I haven't found the time to fix it.
My working in linux post here:
http://forum.openmpt.org/index.php?topic=894.0
Thinking about it you used to be able to compile cedega from source, it just lacked the code that enabled most win games protection systems to work, but it should still work with modplug as we don't need that code for it :D
Take a look on the cedega site http://www.transgaming.org might be some info about the CVS server etc there to compiel it from source.
I'll try it out meself if I ever get my linux box up again.
Asharin, I appreciate the effort but most of us are probably not interested in a solution that involves either buying Cedega or building it from source, especially since Wine comes stock on any Linux machine these days and is almost as good with a little effort.
Our primary goal here is to get OpenMPT first working under Wine, then compile it against the Wine libs. But thanks for letting us know. =)
I believe I said that myself a few posts ago:
Quote from: "Asharin"But could it not be compiled against the WINE libraries making it more or less 100% compatible with WINE under linux?
I mentioned Cedega (ideally compiled version) as a way to run it NOW while waiting.
As for not wanting to compile stuff..why not it's the staple diet of Linux! How do you think we managed before RPM's and DEB etc became more common methods of distribution. I have to admit though, I am just as lazy, I'd rather just install stuff than compile it myself :D
Quote from: "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).
Has anybody already tried to compile it?
I wonder if one has to write a Makefile or to convert the vcproj file before compiling. If so, is there an easy way to automate this step? And if not, how is it done?
Quote from: "cubaxd"Has anybody already tried to compile it?
I wonder if one has to write a Makefile or to convert the vcproj file before compiling. If so, is there an easy way to automate this step? And if not, how is it done?
It would have to be done manually, and it would probably be alot of work, especially if the code uses MSVC(Microsoft) specific features.
Quote from: "Randilyn"Quote from: "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 :P 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 :P
".wild.001" works well. Aside from that, I cannot add any relevant information that has not already been stated.
Could we maybe get this thread stickied? I think it's an important subject worth keeping track of,,,
I just tried FamiTracker (http://famitracker.shoodot.net/) 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
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.
Quote from: "HvitRavn"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).
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 (;
Quote from: "HvitRavn"Actually VMWare Server is gratis :)
Wow, I didn't know. Cool :D .
Quote from: "HvitRavn"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: ).
Quote from: "pelya"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 (http://ygrabit.steinberg.de/~ygrabit/public_html/vstsdk/OnlineDoc/VST_Module_Architecture_SDK/index.html) (provided by the VST SDK (http://www.steinberg.de/331+M52087573ab0.html)) instead in order to remain compliant with all programs that can load them. Said API could eventually be implemented using High Level Emulation (http://en.wikipedia.org/wiki/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 (http://en.wikipedia.org/wiki/Virtual_Studio_Technology#GNU.2FLinux_support).
But there are better (http://www.berotracker.de/) trackers (http://www.renoise.com/) 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.
Quote from: "Randilyn"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.
Quote from: "Randilyn"I just tried FamiTracker (http://famitracker.shoodot.net/) 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
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 (http://www.dll-files.com/dllindex/dll-files.shtml?winhttp) 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 8) .
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 ;D - thank you, Wine guys!
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 ;-)
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.
Why not ditch MFC (platfom-specific, old and slow proprietary gui lib) and start using something like QT4 (multi-platform, open gui lib)?
Quote from: "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 :)
Quote from: "Relabsoluness"why not rewrite most of the program from scratch?
great idea! :D
Quote from: "Relabsoluness"Quote from: "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.
.
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 (http://www.4shared.com/file/21053171/56796244/OpenMPTWine-0941GCC-412Kubuntu-7047-days-of-brainfuck-still-not-linkabletar.html) 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 (http://msdn2.microsoft.com/en-us/vstudio/aa718364.aspx) 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 (http://www.7-zip.org/) to unpack .tar.bz2 on Windows :wink: . Or download in ZIP (http://www.4shared.com/file/21055881/fb5b1ad8/OpenMPTWine-0941GCC-412Kubuntu-7047-days-of-brainfuck-still-not-linkable.html) - 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 :nuts: (I just have no time). So, here's the archive (http://www.4shared.com/file/21197557/beba4dc/OpenMPT-r191-Wine-0942-GCC-412-Kubuntu-704-Compiles-Links-Not-Workstar.html) ( or ZIP archive (http://www.4shared.com/file/21197771/d33ab705/OpenMPT-r191-Wine-0942-GCC-412-Kubuntu-704-Compiles-Links-Not-Works.html) ). 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 (http://sourceforge.net/project/showfiles.php?group_id=2435) 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 (http://www.4shared.com/file/21767803/2d20731f/OpenMPT-r191-MinGW-513-gcc-g-421-sjlj-1-Not-Linkstar.html) (or ZIP archive (http://www.4shared.com/file/21767802/5a274389/OpenMPT-r191-MinGW-513-gcc-g-421-sjlj-1-Not-Links.html)) contains "wrc" utility from Wine compiled by me for win32 - MinGW "windres" cannot handle modern .RC files.
Finally it compiles and works! .tar.bz archive (http://www.4shared.com/file/21944060/be1f4965/OpenMPT-r191--MinGW-513--gcc-g-421-sjlj-1--Finally-Works-tar.html), .ZIP archive (http://www.4shared.com/file/21944059/eceea202/OpenMPT-r191--MinGW-513--gcc-g-421-sjlj-1--Finally-Works-.html), .DIFF file for SVN (http://www.4shared.com/file/21944386/cbb97f87/OpenMPT-r191--MinGW-513--gcc-g-421-sjlj-1--Finally-Works-diff.html). 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) (http://sf.net/project/showfiles.php?group_id=2435) . Then boldly go to "OpenMPT/mptrack" dir, squarely execute "mingw32-make debug" or "mingw32-make release" and pray for success ;D . The debug .EXE will be about 250Mb :D , 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: ).
Quote from: "pelya"The debug .EXE will be about 250Mb
250 Mb? :o
Quote from: "pelya"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) ;)
Quote from: "Relabsoluness"Quote from: "pelya"The debug .EXE will be about 250Mb
250 Mb? :o
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 (http://www.4shared.com/file/22018691/dedc6213/OpenMPT-r191--MinGW-513--gcc-g-421-sjlj-1--Works-but-Crashes-.html) .tar.bz2 (http://www.4shared.com/file/22018694/aeb6969c/OpenMPT-r191--MinGW-513--gcc-g-421-sjlj-1--Works-but-Crashes-tar.html) .diff (http://www.4shared.com/file/22018690/a9db5285/OpenMPT-r191--MinGW-513--gcc-g-421-sjlj-1--Works-but-Crashes-diff.html) (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.
Quote from: "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.
Quote from: "Relabsoluness"Quote from: "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 :D . Now both GDB for Windows and winedbg are working fine on MPT EXE, so theoretically I can develop without Windows at all :nuts: .
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 (http://www.4shared.com/file/23199930/bd8f0987/OpenMPT-r191--MinGW-513--Seems-to-Work--.html) or .tar.bz (http://www.4shared.com/file/23199931/ca883911/OpenMPT-r191--MinGW-513--Seems-to-Work--tar.html) 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 (http://www.4shared.com/file/23200289/dd7ed85c/OpenMPT-r191--MinGW-513--Seems-to-Work--EXE.html) to report me how it works ;D .
Edit: Fixed a bug with assembler code (hoping the last one) and added VSTi Slave Mode. No .tar.bz, just ZIP this time (http://www.4shared.com/file/23750277/2573f757/OpenMPT-r191--MinGW-513--Seems-to-Work--VSTi--.html). When run as VSTi Slave the debug version crashes on Windows but works on Wine, release seems to work everywhere.
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):
QuoteWhat 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?
Just updated VSTi (http://www.4shared.com/file/24451051/62dcfcb/OpenMPT-r191--MinGW-513--Seems-to-Work--VSTi-02--.html)
Edit: diff file for VSTi without any MinGW stuff (http://www.4shared.com/file/24928069/506d947e/OpenMPT_r191_VSTidiff.html)
Fix for VST plugins with same identifier (all of JS plugins are reported to have the same ID) - just diff file (http://www.4shared.com/file/25455345/33081829/OpenMPT-r191--VST-Plugins-ID--.html)
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.
Quote from: "Jojo"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.
Quote from: "pelya"Try running "wineconfig" and tweak some options.
wow, that was precise.
openmpt looks for the default.mkb in its own directory, doesn't it? i even deleted the ini file but there's no effect.
EDIT: I placed the default.mkb file in my documents folder, at least this bug is gone. however, openmpt still crashes some seconds after starting up. there are only 2 lines in the INI file:
[DLS Banks]
NumBanks=0