Re: [fluid-dev] Fluidsynth changes

[Ken Restivo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Apr 27, 2007 at 12:24:09PM +0200, Miguel Lobo wrote:
> HI Ken,
> 
> There are some uses of FluidSynth I'm not familiar with and I would like to
> know more about these use cases.
> 
> For me, as a pretty heavy user of fluidsynth (it's my main instrument), the
> >top things I'd request are:
> 
> 
> Could you describe in a bit more detail how you use FluidSynth?  Do you have
> a MIDI keyboard connected to your computer and use FluidSynth to generate
> the sound?

Basically I play it as an instrument, with a MIDI controller. I have just 
bought a laptop to replace my desktop, and am almost done configuring it... I 
intend to use it to play live. My main instrument is a Rhodes soundfont through 
fluidsynth and then though ecasound with a bunch of LADSPA plulgins. I also use 
a piano soundfont, and for recording I also usually have a fretless bass 
soundfont loaded as well.

My MIDI controller + laptop is a lot more portable than hauling a Rhodes Stage 
Piano around. It gives me other sounds too, it's *much* cheaper than buying a 
Nord Clavia, and it gives me the flexibility to play a bunch of other 
softsynths as well-- all in a pretty compact package.

> 
> 1) Streaming to use less memory.
> 
> 
> I'm not sure what this is.  Perhaps reading the soundfont information
> on-demand from disk instead of storing it in memory?  Are soundfonts really
> so big that memory pressure is a problem in modern computers?

It is if you're running a bunch of large soundfonts simultaneously. I use a 
multilayer Steinway Piano soundfont that is 80MB, a Rhodes that is 15MB, a 
fretless that is 11MB... all this stuff adds up. Especially since I also run a 
bunch of other apps too.

> 
> Quite often you can make a design trade-off between worst-case latency and
> memory usage.  I would have thought that for most uses the former would be
> more important.

It is. The streaming design ideas were discussed on this list before. IIRC, the 
problem is that fluidsynth loads the entire soundfont into memory, even if you 
never use most of the patches, they're all sitting there sucking up RAM that is 
locked down in the case of JACK. This is particularly wasteful when using large 
GM or multilayer soundfonts. Some additional latency at the moment I issue a 
patch change isn't going to bother me.  I'd like to see it:
        a) only load the patches into RAM that have been selected (via MIDI 
program change)
        b) if there's only one MIDI channel, load only the default patch 0 on 
that channel, and none on the others.
        c) for dealing with large, multilayer soundfonts, perhaps it would be 
nice to have it only load individual samples as needed, but I don't need that 
level of granularity right now, and I might be willing to trade RAM for CPU 
cycles in that case anyway.

I think linuxsampler already does (c) and AFAICT its performance is pretty good.

> 
> 2) Enhance realtime performance with JACK. It's already pretty tight AFAICT.
> >But I'd hope you were able to stay focussed on realtime and JACK.
> >Particularly with heavily-multilayered soundfonts.
> 
> 
> >3) Support 24-bit soundfonts.
> >
> >4) Multi-core CPU support! Soon almost every machine shipped will be dual
> >core or quad core. jackmp has some excellent capabilities for efficiently
> >using those multiple cores, but the applications have to take advantage of
> >it. There wassome recent discussion on the jack list regarding this.
> >
> >5) Some way to do the MIDI routing through a conf file instead of having
> >to telnet into the thing (if you use glib, you get its built-in API for 
> >conf
> >file reading/parsing, IIRC).
> 
> 
> What MIDI routing capabilities do you require from FluidSynth?  I thought
> ALSA already implemented pretty flexible MIDI routing?

The functionality I need appears already to be in fluidsynth. All I need here 
is the ability to control it from a conf file, instead of from its telnet 
interface. 

> 
> 6) Please keep it lightweight and command-line/daemon oriented, and resist
> >the GUI temptation.
> >
> >So just my humble requests. Fluidsynth is a great synth and again, it's my
> >main instrument.
> 
> 
> Sorry for the many questions, and thanks in advance for any answers.
> 

No problem, thanks for asking!

- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGMiUJe8HF+6xeOIcRAjZkAKC0y1oq7jXIcwi7gK0eVJgD7fa6vQCg5u+U
jKklKAyElliFMQ2Rx+hGRWY=
=6QoD
-----END PGP SIGNATURE-----