24 Apr
2007
24 Apr
'07
10:09 p.m.
Le Tue, 24 Apr 2007 09:41:17 +0100 (WEST),
"Rui Nuno Capela" <rncbc(a)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.