Re: [fluid-dev] Multi-engine soundfonts

[Josh Green]

On Sun, 2005-10-16 at 19:43 -0600, Dave Serls wrote:
> In order to generate separate synth output streams for 2 midi input channels,
> I've been successful with in a small scale test with qsynth.
> A cursory (and posssibly incorrect) overview of the code indicates that on an
> RT system with mlock enabled, the entire sample-data of each soundfont will
> be loaded in pinned memory (if possible).  With large soundfonts this can be
> crippling.
> 

Yes, thats correct.  The entire SoundFont is loaded into memory when
using FluidSynth.  One alternative to this would be to implement sample
streaming, which Peter Hanappe had talked about before.  It has not yet
been implemented though.

> Ideally, only the sample-data for active presets should be fixed in storage, 
> right?

In order for FluidSynth to respond fast enough after a preset change
(say in a MIDI file) it makes sense to have all instruments pre-loaded.
It can take a significant amount of time to load all samples of an
instrument, and by that time notes could be lost.  If all used
instruments were known before hand than, sure it makes sense to only
load those.  One could make a smaller SoundFont in that case though.

> That aside, could a secondary engine use the soundfont data of the primary 
> engine,
> with the addition of an API call like
> 
> fluid_synth_t*
> new_fluid_synth(fluid_settings_t *settings, fluid_synth_t *primary) 
> 
> which ignores soundfont loading and uses the information of the primary?
> 
> or could this be done with a special soundfont loader?
> 
> I guess what I really want to know is -- is the pinned memory used for
> soundfonts read-only?  If so, it should be usable by all engines.
> 

It is read only, so yes it could be shared between synth instances.

> I was programmer once upon a time in a remote galaxy, but this is looking a 
> bit
> distant even for me.
> 
> Thanks for any hints.
> 

These features are definitely something that FluidSynth could benefit
from and are on the TODO list.  Unfortunately Swami is kind of my
priority currently, which is rather time consuming in itself.  Swami
does its own sample management and allocation.  Currently it loads
samples on demand (not streamed), but isn't very real time aware.  In
the future I see libinstpatch/libswami as becoming a synthesis interface
to FluidSynth providing support for additional formats as well (does
this already to some extent).

Realistically, FluidSynth could really use some help.  I would like to
add features to it, but I find it eats up a lot of time that I could be
dedicating to other projects.  FluidSynth really does need some TLC
though.  If anyone is interested in contributing, feel free to step in.
I'll provide CVS access to those who seem willing and able.  I'll likely
be adding features, fixing bugs, etc as time goes on, but its going to
take a lot longer than if I was entirely dedicated to this project.  


Best regards,
        Josh