Re: [LAU] Alternative Fluidsynth Manager

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@email-addr-hidden
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user