Hallo, Josh Green hat gesagt: // Josh Green wrote:

Cool. From looking at the backtrace a quick fix would probably be to disable LADSPA support in FluidSynth (you probably aren't using it anyways?) Just don't explicitly enable it during configure time and it should not be compiled.

I did that now (BTW: --enable-ladspa=no and --disable-ladspa did *not* disable LADSPA, although that would be nice. But leaving out the option at all as you suggested worked).

Disabling LADSPA in libfluidsynth indeed did the trick for fluid~: fluid~ is up and running again now. I do wonder: The fluid-settings I used inside fluid~ explicitly disabled ladspa (as copied over from the fluidsynth source code). Normally it shouldn't go that ladspa path anyway then, not?

fluid~ normally disables all effect processing because users can do that in Pd, which is a modular synth, themselves if they want to. Pd is a LADSPA host.

There may be something more sinister going on here though, since I really don't see how its getting to delete_fluid_settings() from fluid_settings_getint(). Something might be broken with the LADSPA code. I may have to get ~FluidSynth installed to figure this out. Any quick pointers to getting things setup?

If you're on Debian unstable the easiest way to get this up and running is to do:

$ apt-get install pd-flext-ext

or to get the source with build-dependencies

$ apt-get build-dep pd-flext-ext ; apt-get --build source pd-flext-ext

fluid~ is part of the pd-flext-ext package.

The CVS way is to check-out the externals-tree from pure-data.sf.net and then first build externals/grill/flext and after that externals/footils/fluid with some editing of the respective config-pd-linux.txt files in both directories to match your paths.

Of course you also need Pd installed.

ciao