24 Apr
2007
24 Apr
'07
6:42 a.m.
On Mon, April 23, 2007 22:53, lanas wrote:
Folks,
Is there anything else out there than QSynth for managing fluidsynth
synths ?
I run into too many bail outs from QSynth to be confortable and
trusting with it. Sometimes it'd just bail out when doing 'setup' on the
fifth instance of a synth, to load a soundfont.
I might be tempted to write one. As far as I see it now, the
documentation for both fluidsynth and qsynth consist mostly of the source
code itself. Without even knowing how it works, I'd like to be able to
set at least the volume of each instrument inside a loaded soundfont.
qsynth has only a global volume for each instance of a sf. But then, maybe
that's calling for something like re-writing the sf player altogether.
It'd be also fun to have separate audio outputs for
each instrument coming out of a soundfont.
In the meanwhile, is there any alternative soundfont player/manager
out there that's worthy of being stable and trustable ?
Cheers.
There's the fluidsynth-DSSI plugin ... muse sequencer also used to have
fludisynth integrated.
But wait, if you're seeing trouble on the Qsynth front, how about trying
to have some bug reports in the first place? ;)
To be honest, I already know that Qsynth bails out from time to time,
specially when dealing with more than a couple of engines (ie. fludisynth
instances). Incidentally, the problem arises infrequently on engine
stop/start (after setup).
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.
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 :)
OK. I'm not saying you should not look around for alternatives, but I'm
afraid you'll face the same behavior once you start stressing the
fluidsynth run-time bootstrap dynamics with your newer choice :)
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. Just a thought.
Cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org