How long did libopenmpt take to make?

[minebrandon]

I've been constantly talking to cs127 about how OpenMPT should "fix" it's UI as in not use MFC so that it can be ported to run natively on Linux without Wine. I know that the playback was "fixed" in I think 2013(every time I check, it turns out it was released a year earlier than I thought) with libopenmpt, but I don't know a lot about libopenmpt's development, so I want to know a few things. First off, when did it start development? I know that it stated work on with the current developers, but I don't know if it was started a year or two prior or if it was started immediately in the late 2000s. I also want to know how much the code base being less windows reliant and libopenmpt being was developed, was it sort of a backburner task while other features were being worked on, or was it the main priority and nothing else was being added to OpenMPT at the time? Was the development all a conceited effort through and through, or were there massive ebbs and flows in how much it was being worked on? Was the getting off windows a priority from the start, or was that decided later on? Also if months/dates could be provided that'd be nice as it's annoying to say "2013" or "2008" without any reference on where in the year that was.

[manx]

I've been constantly talking to cs127 about how OpenMPT should "fix" it's UI as in not use MFC so that it can be ported to run natively on Linux without Wine.

Can you please move such discussion to a/(any) public forum? We already have an issue tracker issue (https://bugs.openmpt.org/view.php?id=783) that tries to track everything roughly related to that (this includes all transitively linked issues). It would be great if you could just either start new issues or amend existing ones if the topic fits with summeries of your discussions.

I know that the playback was "fixed" in I think 2013 (every time I check, it turns out it was released a year earlier than I thought) with libopenmpt, but I don't know a lot about libopenmpt's development, so I want to know a few things. First off, when did it start development? I know that it stated work on with the current developers, but I don't know if it was started a year or two prior or if it was started immediately in the late 2000s.

libopenmpt development effectively began when I joined OpenMPT, which, according to https://github.com/OpenMPT/openmpt/blob/f57280eee841ac2bf1f817914ff40f9086bab718/common/version.cpp#L603-L623 and https://github.com/OpenMPT/openmpt/blob/f57280eee841ac2bf1f817914ff40f9086bab718/packageTemplate/History.txt#L13-L21 was sometime in 2012. Saga Musix and I had been talking about the module playback situation on non-Windows systems before that at Demoparties for about 1 or 2 years I guess.

I also want to know how much the code base being less windows reliant and libopenmpt being was developed, was it sort of a backburner task while other features were being worked on, or was it the main priority and nothing else was being added to OpenMPT at the time? Was the development all a conceited effort through and through, or were there massive ebbs and flows in how much it was being worked on?

I would say, it was an integrated approach for the most part. I mainly had joined OpenMPT with the intention of moving it towards a cross-platform playback library. I never felt it was the right approach to only work solely on that though, thus I also worked on tasks only related to OpenMPT itself.

We converted the playback code to be usable alone basically while still keeping the whole code base working and releasable as OpenMPT. This was frankly one of the main goals, and still is, because we very much wanted to avoid divergence between libopenmpt and OpenMPT like it had happened before between libmodplug and OpenMPT, see https://openmpt.org/legacy_software, https://lib.openmpt.org/libopenmpt/faq/, and https://buildbot.openmpt.org/history/ for more context on that history.

There were various things to clean up (in no specific order, and probably not a complete list):

• MSVC-specific language extensions
• global state (inappropriate for a thread-safe library)
• entanglement of UI code and playback code that had creeped in over the years (note that originally, ModPlugTracker and ModPlugPlayer had a shared code base)
• build system and dependency handling
• x86-specific assembler code
• Windows-specific API usage and assumptions
• portable character set handling

The details of that process and everything related to that could likely fill multiple long blog posts.

As the API facade on top of the shared code base (which libopenmpt still is and should remain), libopenmpt was implemented in probably a week or so, once the foundation was set. Porting to non-MSVC/non-Windows really only started after that, because before that there was not really anything that could sensibly be ported and (compile-)tested because of the MFC dependency.

With the release of libopenmpt 0.3 (2017), OpenMPT switched from a trunk-only development model to using release-branches, which was somewhat necessary to be able to sensibly maintain older versions (of both, OpenMPT and libopenmpt) with bug fixes while shielding them from major refactoring or development work on a shared trunk. This is probably also the main reason why we use SVN instead of GIT. GIT is awful at that development model without additional tools that track cherry-picking (in git-speak) / selective-merging (in svn-speak).

Was the getting off windows a priority from the start, or was that decided later on?

That was a goal from the start, and still is.

Also if months/dates could be provided that'd be nice as it's annoying to say "2013" or "2008" without any reference on where in the year that was.

Well, everything is in the SVN repository at https://source.openmpt.org/svn/openmpt/ (not sure how good the development-branches that we used early on are mapped to GIT (https://github.com/OpenMPT/openmpt/), but in theory the commits should also all be there).

[Saga Musix]

Also, just to make it obvious: Because the playback code was already platform-independent at some point, it was relatively easy to bring it back to that state. It's not like it was suddenly full of UI code interspersed with audio rendering. It was more like some careless changes that e.g. would require access to the OpenMPT settings (stored in tracker code, not playback library code), using MFC's CString type for strings in custom tunings, tracker-specific features being tied too closely to the playback code (e.g. MIDI mapping), etc. Those were indepdently manageable issues that could all be eliminated in a concentrated effort over the period of a year or so, as manx says. This cannot really be compared to making code platform-independent that was never meant to be portable (i.e. the MFC-based UI code). There's a lot more to be cleaned up and rewritten, all while still being able to release updates to OpenMPT. That said, a lot of efforts towards this goal have already been made during the previous years. We're definitely closer to having a platform-independent OpenMPT compared to, say, five years ago.