Why LSP Plugins have been split into the tons of repositories?

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

Post Reply
User avatar
sadko4u
Established Member
Posts: 987
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 360 times

Why LSP Plugins have been split into the tons of repositories?

Post by sadko4u »

Hello all!
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.
Of course, so 'compartmentalisation' has it's own drawbacks. And the primary drawback is that it is much harder to manage code as we did for the single repository. For example, I was required to write some scripts that automate some things that I did by hand previously. But that gives another advantage: each sub-project can live with it's own life.

So we have at this moment: So that's the main reason why the code has been split into dedicated repositories.
LSP (Linux Studio Plugins) Developer and Maintainer.
tseaver
Established Member
Posts: 398
Joined: Mon Mar 13, 2017 6:07 am
Has thanked: 11 times
Been thanked: 98 times

Re: Why LSP Plugins have been split into the tons of repositories?

Post by tseaver »

FWIW, I've been through a similar process at *least* twice in my FLOSS-developer career, and I wholeheartedly concur that splitting a mono-repository is a better experience for nearly everybody. There are minor costs for the "I develop everything myself" maintainer, but even for that person, being able to make a bugfix release for a single library without touching any of the others is a huge win.

As you note, the split also allows improving the overall code quality (no "accidental" coverage), which is most gratifying.
Ubuntu, Mixbus32C; acoustic blues / country / jazz
GMoon
Established Member
Posts: 51
Joined: Sat Oct 03, 2020 1:10 pm
Has thanked: 11 times
Been thanked: 20 times

Re: Why LSP Plugins have been split into the tons of repositories?

Post by GMoon »

Yeah, I also see this as a positive. I'll just cite previous versions of the CAPS plugins (in the LADSPA era)-- I really liked the earlier Cabinet sims and some distortion plugins.

But the CAPS API is all or nothing. It's all so tightly coupled that simply renaming and compiling a previous version of one or two plugins is quite difficult. Sure, the newer versions are "improved," more efficient, etc. -- but don't sound the same. Yes, you can copy the 'guts' and write a new plugin, but that's not for the general user.

(plugin versions are a bit of a sticky problem, IMHO.)
Basslint
Established Member
Posts: 1511
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy
Has thanked: 382 times
Been thanked: 298 times

Re: Why LSP Plugins have been split into the tons of repositories?

Post by Basslint »

Thank you for sharing with us your knowledge, @sadko4u. It's not something all software engineers do! :D
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]

Please donate time (even bug reports) or money to libre software 🎁

Jam on openSUSE + GeekosDAW!
Post Reply