> 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. <tom.m...@googlemail.com>:
>
> > > 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
>
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
