Hi Ahmed,
2017-11-13 1:53 GMT+01:00 Ahmed Eraiba :
> Yes I get exactly the same problem with the master branch build, ie.
> builds successfuly, giving void function warnings and throws the same
> exceptions!
>
Ok, that is good to know. But what exactly do you mean by "exceptions"? C
doesn't have
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, l
On Mon, Nov 13, 2017 at 3:39 PM, Tom M. wrote:
> > 3. It wouldn't make sense to change ladspa.h if it was included in
> fluidsynth. So it wouldn't be a fork.
>
> People tend to have fancy ideas ;)
>
>
> > 4. If ladspa.h "upstream" would change in a way that would force plugins
> to be recompiled
I dont think this is an option for upstream. We also use libsndfile
for the filerenderer and we cant introduce a fallback library for
every dependency we are using.
Tom
2017-11-13 15:28 GMT+01:00 Philippe Simons :
> i'd like to add support for SF3 to my android fork, but I'd like to avoid to
>
> 3. It wouldn't make sense to change ladspa.h if it was included in
> fluidsynth. So it wouldn't be a fork.
People tend to have fancy ideas ;)
> 4. If ladspa.h "upstream" would change in a way that would force plugins to
> be recompiled (and this won't happen), the only required change in flu
i'd like to add support for SF3 to my android fork, but I'd like to avoid
to add a dep on libsndfile (shouldn't be impossible).
what do you think to include std_vorbis from http://nothings.org/ if
libsndfile is not available ?
___
fluid-dev mailing list
>I'm proposing to bundle the compile-time dependency (i.e. the ladspa.h header
>file) with FluidSynth and remove the compile-time switches and "#ifdef LADSPA"
>from the >codebase.
It would be a turn in a sad direction.
The great force of FluidSynth library is that it is made of 4 smalls modu
2017-11-13 11:33 GMT+01:00 Kjetil Matheussen :
> 1. Ladspa is set in stone. It has mostly been replaced by lv2 now. (lv2
> stands for ladspa v2.)
> 2. ladspa.h can't change too much because then the plugins would have to
> be recompiled.
> 3. It wouldn't make sense to change ladspa.h if it was inc
2017-11-13 10:38 GMT+01:00 Philippe Simons :
> ok, please take into account that on some system LADSPA is just not
> available
>
That is a good argument against enabling it by default. Thanks, I
completely forgot about Android or iOS. I guess it would be possible to
compile the LADSPA code for An
On Mon, Nov 13, 2017 at 11:09 AM, Tom M. wrote:
> > I'm proposing to bundle the compile-time dependency (i.e. the ladspa.h
> header file) with FluidSynth
>
> I vote against it. Even if it's only a single header file, bundling it
> with fluidsynth would mean to fork LADSPA. Look at with the people
> I'm proposing to bundle the compile-time dependency (i.e. the ladspa.h header
> file) with FluidSynth
I vote against it. Even if it's only a single header file, bundling it
with fluidsynth would mean to fork LADSPA. Look at with the people at
MuseScore did with fluidsynth: In 2012 (when fluidsy
ok, please take into account that on some system LADSPA is just not
available
I'd like to avoid making more changes in my branch to be able to compile
fluidsynth for android
On Mon, Nov 13, 2017 at 10:02 AM, Marcus Weseloh wrote:
> Hi all,
>
> as the LADSPA subsystem has been cleaned up and has
Hi all,
as the LADSPA subsystem has been cleaned up and has been shown to also work
on WIndows, I'm proposing to bundle the compile-time dependency (i.e. the
ladspa.h header file) with FluidSynth and remove the compile-time switches
and "#ifdef LADSPA" from the codebase.
LADSPA isn't actively dev
13 matches
Mail list logo
