Hi,
2017-11-11 19:07 GMT+01:00 Tom M. :
> 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 th
> 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 ad
2017-11-11 10:23 GMT+01:00 Tom M. :
> > 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 a
> 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() ?
> I gue
Hi all (and especially Tom),
I would like to expose some (or most) of the public functions in
src/bindings/fluid_ladspa.h as a public API. Now I'm wondering how to do
that, given the fact that LADSPA can be disabled at compile time. I guess
we need to mock those functions if LADSPA isn't available
