Porting to Linux

[Atlantis]

My brother is a very skilled programmer. He'd like to see it ported to Linux, but the code seems to be specifically made for Windows. "It's a shame they're still using subversion, and haven't jumped on the GIT bandwagon yet". He says he can help with the top "to do" list (getting rid of the buggy MFC code. Instead use something like Qt.), but he is not keen to set up a Windows environment to do so (he uses Linux). Also, "considering it uses MFC (Microsoft foundation classes, which is quite old now), you probably need visual studio to compile it too, which I am not going to buy in a million years, I'd rather use GCC as a compiler." As I say, he is very skilled in what he does, but doesn't seem to have the time. Just thought I'd put that out there. If anyone wants to talk to him, I can provide you his contact.

Also, while I'm at it, please remove that stupid bass expansion, reverb, surround, volume ramping and EQ in the Setup! Who still uses that, anyway? I know it's all off by default, but there's still no need for it.

[Saga Musix]

There is a Visual Studio Pro trival available which comes with MFC; I'd rather work together with someone who has insight into the program and can compile the code; not somehow who has no idea how it works and refuses to get the tools needed to make it run in its current form. Linux hippies, ts....
(Don't get me wrong, I don't hate Linux, but I can't stand people who refuse to use anything else)

Also, while I'm at it, please remove that stupid bass expansion, reverb, surround, volume ramping and EQ in the Setup! Who still uses that, anyway? I know it's all off by default, but there's still no need for it.

It has to go away sooner or later anyway, because everything except the EQ is written in x86 ASM; the experimental x64 builds have those functions disabled for that reason. The EQ can be nice for what the label below it says - compensating for deficiencies of your audio hardware. But it's not a very HQ EQ, so it would probably make sense to rewrite / replace it rather than keeping it as it is.

[enkore]

With git-svn there isn't really a need for master to be git...

Anyways, porting to Qt would be quite a long-term project I guess as MPT uses lots and lots of custom controls and views — those are (way) easier to do with Qt, but want to be written anyway. A complete Qt port would still, of course, not run natively on Linux or other unices, as there is some stuff, which depends on rather low-level Windows services (sound output, MIDI and stuff like that ... from a quick glimpse at the code).

tl;dr porting to qt would be step 1 of 3 to get it to run under other OS
1. port to qt
2. write OS specific services
3. write plugin glue code for AU, LADSPA/DSSI and/or LV2.

[Saga Musix]

Yes, this port is most definitely a long-term project. But in fact, sound output doesn't require any further work because we already use portaudio for several drivers where rolling our own, new code would be too much work (read: WASAPI, Kernel Streaming). The existing code for DSound/WaveOut/ASIO would simply be disabled for non-Windows platforms. MIDI is also trivial to replace, since there's portmidi. The actualy platform-dependent MIDI code is only a few lines, all the important stuff is naturally platform-independent.
The much bigger problem is still the GUI and everything that's related, especially rebuilding everything while staying as true to the original look&feel as possible. The most complicated custom control to port would most likely be the pattern editor, sample and envelope editors should be rather trivial (writing a *fast* waveform display will still be an interesting exercise, though). I imagine that the keyboard handling code will also be a lot of "fun" to port.
Luckily, two other big blocks (making libopenmpt cross-platform and making OpenMPT x64-ready) are already done.

[enkore]

Maybe GSoC '14 is worth a try?

Anyways I won't make the mistake and promise something, but I'll take a deeper look at the code.