Re: [fluid-dev] Bundling ladspa.h

[Marcus Weseloh]

Hi all,

this discussion has stalled, so let me summarize the recent posts...

Most importantly: I have abandoned the idea of removing the #ifdef's around the LADSPA code. There were very good arguments against it. Thanks for your input!

So we are left with the idea of bundling the ladspa.h header file. On most Linux distributions, it is very easy to install the LADSPA SDK including the analyseplugin and listplugin tools and ladsa.h header file. So bundling it would probably be most useful on Windows. And given the fact LADSPA on Windows is quite unusual and that Tom seems to have a strong opinion against bundling, I'm withdrawing that suggestion as well.

Cheers,

    Marcus

2017-11-13 17:49 GMT+01:00 Marcus Weseloh <address@hidden>:

Hi JJC,

generally I agree that removing the #ifdef's from LADSPA is not a good idea after all. Mainly because of the Android and iOS use-cases that I completely forgot about. But also because LADSPA is currently the only part that requires gmodule. However, some of your comments I disagree with, let me explain why.

2017-11-13 15:03 GMT+01:00 Ceresa Jean-Jacques <jean-jacques.ceresa@orange.fr>:

The great force of FluidSynth library is that it is made of 4 smalls modules completely independent (In short, the synthesizer, the audio driver , the sequencer, and the midifile loader). This concept is particularly well suited for embedded applications subsystems. Any developer is able to keep only the modules he need.

I also like the code separation and (more or less) clear APIs between the different parts a lot. Yet... those "modules", as you call them, are always compiled into libfluidsynth. There's no compile-time switch to disable the midifile loader or the sequencer. And there doesn't need to be, to have this nice separation of parts that you describe. 

The great interest is to keep the synthesizer module (i.e codebase) as light and understandable as possible for developper and reviewer.  So if any application doesn't not need any LADSPA at all, that here no reason that this synthetizer module became fat (as thoses  glib shared  library became). (As an example for embedded systems the fluidsynth library  is about 188ko and its need a shared glib library of 1215ko and FluidSynyh is using only less than 5ko of code inside this stupid shared library).

I don't see why LADSPA would make the synthesizer module fat. The LADSPA code is completely self contained and has a clear API (or at least that's what I was aiming for). It's so separated from the rest that you could even use it as a standalone LADSPA host, without using any other parts of FluidSynth. There are only three places in the FluidSynth synthesizer where ladspa code is being called, and they are probably around 30 lines of code when added together. There's more in the fluid_cmd.c, but that is just for the command-line interface parsing. So I really disagree here: having lot's of #ifdef's in the codebase doesn't make that code disappear, it doesn't make the codebase lighter or easier to maintain and doesn't make it more understandable. I think it quite the opposite is true.

And the embedded use-case you describe, where the size of the libfluidsynth and glib libraries matter doesn't sound very convincing to me. If the embedded system is so space and resource constrained that <2MB dependency libs are a problem, then you would need to get rid of glib anyway. And there is currently work underway by loki666/Philippe Simons to change the FluidSynth source so that fluid_sys and fluid_priv can be overwritten with an OS or even hardware specific version.

So I guess what I want to say is: I think you are right that we need to keep the embedded use-case in mind. We need to make sure that people on very resource-constrained systems can easily modify the source so that they can compile a much smaller FluidSynth. But I don't think that their use-case should prevent us from adding new features into FluidSynth. Just take your polymono patch as an example... it adds a lot of new complexity to the source, and we are probably not going to #ifdef it. So it increases the size of the libfluidsynth lib (also for the embedded use-cases) a little bit and it also increases the runtime memory footprint of FluidSynth. But it will be worth it, because it adds a very nice new feature.

The more FluidSynth will be independant of any others code (as possible) the more it will be easy to maintain for developer and the more it will be easy to use for end users.

That's something I don't completely agree with. Using a mature a well tested library like glib for platform specific stuff doesn't make it harder to maintain the FluidSynth codebase, it makes it much easier.

 

But just let me repeat my opening statement: I agree with you that we shouldn't remove the #ifdef's around LADSPA. I just don't quite go along with your reasoning :-)

All the best,

   Marcus