Re: [fluid-dev] Fluidsynth changes

[Josh Green]

On Fri, 2007-04-27 at 09:30 -0700, Ken Restivo wrote:
> > 
> > 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.
> 

Streaming would be nice too for previewing samples in other applications
(like when importing samples using Swami, not having to load a huge
sample but just streaming it would be a good thing).  The Fluid R3 GM
SoundFont is quite large too (140MB I think).  Theoretically a SoundFont
could be up to 2GB in size, but that is usually associated with
GigaSampler instruments (although there is nothing stopping someone from
doing that with a SoundFont, though it likely couldn't be used with
hardware based SoundFont cards).


> 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.
> 

Yes, linuxsampler does streaming.  Swami does a) and b) using
FluidSynth, since it manages its own instruments.  This could be added
easily to FluidSynth, just takes someone doing it.  I think the next
best step would be to just add libInstPatch support and better
instrument management.

> 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. 
> 

I believe that functionality is already available:
fluidsynth -f configfile.txt

The config file just contains commands like you would type at the
command prompt.

fluidsynth --help
for more info.

> 6) Please keep it lightweight and command-line/daemon oriented, and
resist
> >the GUI temptation.

As far as GUI temptation, there are already several GUI front ends for
FluidSynth.  I think the point you are trying to make is to not have
FluidSynth depend on a GUI.

> - -ken

Best regards,
Josh