Re: [fluid-dev] Expose LADSPA functions via FluidSynth API

[Tom M.]

> So the question really is if the API should expose the ladspa_fx object at 
> all, or if all LADSPA API functions take a synth object instead. My personal 
> aim is to be able to manipulate the synth->ladspa_fx, so the latter option 
> would be best. But it could be useful to be able to create additional 
> ladspa_fx instances... I'm undecided. What do you think?

I would rather prefer exposing (i.e. adding a getter) for synth->ladspa_fx than 
introducing even more synth API functions that in the end would only wrap those 
of fluid_ladspa.h. And having LADSPA API functions taking a synth object to 
manipulate the ladspa instance of the synth object doesnt feels right either.

So I would not mind exposing e.g. fluid_ladspa_add_*() so the user could 
programatically add plugins after synth creation. However for now I would be 
cautious exposing too much functionality like new_fluid_ladspa_fx() or even 
fluid_ladspa_run(). If you ask me, fluidsynth should not become a ladspa 
abstraction library. So as long as there is no specific use case to create 
additional ladspa_fx instances, I would keep it as lightweight as possible.

> Hm... wouldn't fluid_ladspa.h be a better place for the stub declarations?

If you are thinking of preprocessor stub declarations this wouldnt provide ABI 
compatibility. And stub implementations shouldnt be located in public headers. 
That's why I would go with LADSPA API functions that always exist but react 
differently if fluidsynth compiled without ladspa. A public ladspa.h would then 
only consist of forward declarations like:

ladspa.h:
int fluid_ladspa_add_effect(fluid_ladspa_fx_t *fx, const char *effect_name, 
const char *lib_name, const char *plugin_name);
---
fluid_ladspa.c:
int fluid_ladspa_add_effect(fluid_ladspa_fx_t *fx, const char *effect_name, 
const char *lib_name, const char *plugin_name)
{
#ifdef LADSPA
// do business as usual
#else
return FLUID_FAILED;
#endif
}


Tom

Am Samstag, 11. November 2017, 17:03:31 CET schrieb Marcus Weseloh:
> 2017-11-11 10:23 GMT+01:00 Tom M. <address@hidden>:
> 
> > > I would like to expose some (or most) of the public functions in
> > src/bindings/fluid_ladspa.h as a public API.
> >
> > Ok. And what would be its main purpose? Enable the user to manipulate
> > synth->ladspa_fx or create custom ladspa_fx units to manually render audio
> > by calling fluid_ladspa_run() ?
> >
> 
> Good question! So the question really is if the API should expose the
> ladspa_fx object at all, or if all LADSPA API functions take a synth object
> instead. My personal aim is to be able to manipulate the synth->ladspa_fx,
> so the latter option would be best. But it could be useful to be able to
> create additional ladspa_fx instances... I'm undecided. What do you think?
> 
> 
> > > I guess we need to mock those functions if LADSPA isn't available to
> > keep the ABI stable?
> >
> > Correct, by returning NULL or FLUID_FAILED. However #ifdef LADSPA should
> > be placed inside fluid_ladspa.c, I want to keep that as opaque as possible.
> >
> 
> Hm... wouldn't fluid_ladspa.h be a better place for the stub declarations?
> 
> Cheers,
> 
>    Marcus
>