Today I got a very important question about the reasons of splitting a single LSP Plugins repository into many dedicated repositories.
The actual my answer is here: https://github.com/ryukau/LV2Plugins/is ... 1087303034
But I think it could be pretty good to post it here, too.
So, what advantages and disadvantages of the 'compartmentalisation' process of the LSP repository?
The main advantages are:
- The responsibility principle. Having a mono repository, it is just easy to manage it. But when you want to use the only part of this mono repository, then you have troubles. For example, there is a lsp-dsp-lib now which provides low-level DSP processing functions optimized with SIMD for some popular hardware platforms. Trying to extract this library from the whole repository would be very complicated. But now it is very easy, since the library has it's own repository. And such DAWs like Zrythm alreay use it as a part of DSP backend.
- The coupling. When we have mono repository, we manage the code. But even if we do this carefully, we are still exposed to do the tight coupling for the modules. Sometimes it is good, sometimes it is bad. Examples of bad coupling: the back reference from lower-level abstraction layers to the higher-level abstraction layers, huge class hierarchies that go out of domain responsible for some functionality and so on. Splitting some code from the mono repository to dedicated repository guarantees less tight coupling, defines more strict boundaries between domains of responsibility and makes things independent.
- The portability. When I performed the first try to port code to Windows, I met serious problems that I can not rewrite a short piece of code without rewriting the affected code. And even that was not hard to do with some system functions, much more problems were caused when I took on the UI. Decomposition of the mono repository into dedicated repositories allows to do the job with less blood. You just need to ensure that each module compiles for another OS and works properly. That means that some LSP repositories already support Windows, and some of them still not. But it is much easier, for example, to port lsp-ws-lib repository to support Windows rather than rewrite the whole widget subsystem inside of the mono repository and then catch out all of the errors.
- More flexible build process. That means, that we can collect all plugins in a single bundle or produce individual bundle for each plugin. There was a request from falkTX related to MOD Devices to have a possibility to ship different plugin bundles as single packages (like Parametric Equalizers, Compressors, Expanders, etc). I was moving towards that concept and I'm almost done with it. With a mono repository that could be very painful, even if possible at all.
- The better code coverage. I mean, when I moved code from the mono repository to the dedicated repository, I also was required to check for it's correctness. And that's why I was forced to introduce unit tests that validate the proper work for each piece of code I'm moving. I can not actually say that the code is 100% covered by unit tests (and in some cases it is not possible at all) but a lot of work was done to find some hidden errors, and I got a positive experience in that way. As a result, that allowed to eliminate many errors (especially 'dumb' errors) that have been made in the development process and have been hiding like bombs with the long-delayed explosion period.
So we have at this moment:
- The low-level template library which is a counterpart of traditional STL and aims to minimize the amount of code that should be generated by the compiler when dealing with basic data collections like arrays, hash maps, etc: https://github.com/lsp-plugins/lsp-lltl-lib
- The runtime library that provides some cross-platform functions and support of some usual data formats (like XML, JSON and even more): https://github.com/lsp-plugins/lsp-runtime-lib
- The simple test framework that allows one to write unit tests, performance tests and manual tests: https://github.com/lsp-plugins/lsp-test-fw
- The low-level DSP library with SIMD optimizations for some popular hardware architectures: https://github.com/lsp-plugins/lsp-dsp-lib
- The high-level DSP library that provides set of DSP processors which can be used as bricks while introducing your own plugin: https://github.com/lsp-plugins/lsp-dsp-lib
- The window subsystem library that provides the window interface and backend as a single abstraction layer for implementing your own toolkit library: https://github.com/lsp-plugins/lsp-ws-lib
- The toolkit library that allows one to write standalone GUI applications: https://github.com/lsp-plugins/lsp-tk-lib
- The plugin framework that allows one to create your own plugin bundle: https://github.com/lsp-plugins/lsp-plugin-fw