search

bisqwit / adlmidi

ADLMIDI is a MIDI player that uses OPL3 emulation.
59 stars 10 forks source link

Unite with libADLMIDI project #4

Closed Wohlstand closed 3 years ago

Wohlstand commented 5 years ago

While the original ADLMIDI was developed slowly, 4 years ago I have began a fork called libADLMIDI - a library project I have made from off the original sources. The library project was grown into powerful MIDI synthesizer which is now using in various free projects include player plugins and game engines (For example, GZDoom).

There are two ways:

The Library project itself:

https://github.com/Wohlstand/libADLMIDI

It's not only an attempt to bootstrap so outdated original, but also make an ability to change the library part license into LGPLv2.1+ (The related discussion is here: https://github.com/bisqwit/adlmidi/issues/3)

jpcima commented 5 years ago

OK so allow me to give some humble ideas on a strategy plan on how I think this process is best accomplished, according to a modest knowledge I have personally of both projects.

The fact is: we are in front of a massive change set that we desire to have merged in, with @bisqwit's approval and in respect of some constraints he has expressed in the former discussion (for example, to maintain a project build using the Make tool). He has made clear that a contribution must be made not as a whole, but in a nice incremental way.

I think our main goal should be to introduce functionality gradually, in a way which keeps ADLMIDI functional all the way from point A to B. This is likely to be a long and patience-requiring process that will take its needed time to fulfill.

@Wohlstand and I have two needs which add to the original: respectively, game engine and musical intrument needs, which are both met by libADLMIDI in the current state, with all additional requirements which these needs imply.

To get to result, it is likely not acceptable to just take the commit history of libADLMIDI and replay it on top of ADLMIDI. Well, it will lead to the same result for sure as out current libADLMIDI state, but is not going to be humanly reviewable in any reasonable measure.

Here are my thoughts on the matter:

For the obvious part, ADLMIDI cannot be split into a program and library without a minimum of structural changes, as it is made clear by the monolithic nature of midiplay.cc.

At our side, we have a set of distinguished logical components identified: synthesizer, sequencer, player, chips, measurer, etc. The separation of these components is expressed more or less in the file structure of libADLMIDI. I say "more or less" because this structuring is not perfect IMO, but it's not too bad either (example: adlmidi_private.hpp could use some tidying up).

I think this: a fine starting point may be to split ADLMIDI, in such a way that both our projects' file hierarchies match exactly. At the beginning, we should apply the very minimal changes which allows to make this split. This would permit using a diff tool to facilitate the observation of differences between the two projects.

I think this sets up at least a base such that the merge is somewhat workable, if @bisqwit will be favorable to this idea.

Many of elements we have are reorganizations which don't need a particular explanation to understand, but also we have some changes into the channel management and measurer which are by far not so obvious. On this, @Wohlstand has usually the greater knowledge and he has a vast set of MIDI test cases which are able to illustrate various cases of problems.

Wohlstand commented 5 years ago

Added "Lazy way" variant on "library-2" branch:

Wohlstand commented 5 years ago

@bisqwit , pinging you to ask, how are you, and what your thinks about everything that was said here?

P.S. In your make file I have saw the archive creation code, and I think, this thing would completely replace it and let you manage your in-repo stuff much easier: https://git-scm.com/docs/git-archive

bisqwit commented 5 years ago

If you read the depfun.mak file, you’ll notice I actually do use git-archive in depfun.mak where the archives are created. However, I am intentionally keeping the git repository contents separate from the source archives for reasons I cannot recall right now.

As for the ping, yes I prefer the “lazy way” of your two suggestions. I would like to keep a curatorial direction of every single change made to the software — even if that shapes the software a bit differently than you have done — which is why I am not going to approve bulk changes or swaps. Unfortunately I am lacking time to do research on the commits from your repository.

Wohlstand commented 5 years ago

Okay, then, the next step I'll do on the library-2 branch is splitting up the "midiplay.cc" (backporting of my work made by me in 2015'th year) into sub-modules and classes, and then a libraryzation of the result that will get the C API.

P.S. A little message from my another friend for you:

Hauskaa Hanukkaa, hyvää itsenäisyyspäivää ja onnea!🦊

Wohlstand commented 3 years ago

Okay, for this I chose a different way: I did simpler and different. Now this will have the "ADLCPP" library with full C++ API/ABI. libADLMIDI in the current form has major difference from this and approximately half of the original part was completely replaced with different implementations. So, I think, this issue is no longer actual.