[LAU] Alternative Fluidsynth Manager

[lanas]

Le Tue, 24 Apr 2007 09:41:17 +0100 (WEST),
"Rui Nuno Capela" <rncbc at rncbc.org> a écrit :

Hi,

> But wait, if you're seeing trouble on the Qsynth front, how about
> trying to have some bug reports in the first place? ;)

Could do, I guess ,-)

> As far as I could go, and because most of crash occurrences were
> rather random and not as reproducible as my patience required, most
> of the problems were traced down into libfluidsynth, so there's this
> case of you're just beating around the bush when trusting another
> front-end implementation instead of Qsynth's.

That's what I thought could be a good possibility.

> Probably related to this, fludisynth soundfont loader has a rather big
> issue regarding memory leakage, so that each time you start a Qsynth
> engine your RAM will get eaten up, progressively, in small amounts.
> This is a fluidsynth flaw, not Qsynth's, and should be addressed to
> the fluid-dev list, one more time :)

Or maybe rewrite a soundfont player altogether.  Maybe things like
having a separate volume control (at least -reverb and chorus could be
fine also) for each of the 16 sounds that can be played inside a
soundfont archive cannot be achieved with the current fluidsynth player.

Much like Zyn does it as it only has one jack audio entry but for each
synth instance of a single Zyn app the reverb and volume (to name only
these) can be set inside Zyn.

> That's why I would prefer you having some time to put
> qsynth/fluidsynth under gdb harnessing and start pinpointing where
> real trouble tickets are, instead of just fleeing out of illusion.

That's a thought.  Moreover, that's surely the only way to start
something.

Cheers.