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