On Sun, Nov 14, 2010 at 2:00 AM, David Henningsson<address@hidden> wrote:
libInstPatch also has a SoundFont voice cache system
(IpatchSF2VoiceCache), which converts SoundFont presets, instruments
or samples into an array of potential SoundFont voices (selected by
MIDI note and velocity values). This means faster note-on
calculations (than current FluidSynth), since a simple array of
potential voices needs only to be searched, rather than doing
calculations on the SoundFont tree at note-on time (its done at preset
selection time instead).
Hmm, interesting, but wouldn't this make preset selections very slow?
I suppose the actual preset selection operation would be slower than
FluidSynth's existing implementation, but "slower" is a pretty
relative term here. Rather than re-calculating the voice parameters
every note-on, its done only once when a preset selection occurs. I
think its much better to do this during preset selection (a relatively
infrequent operation compared to note-ons) than every note-on. This
calculation is likely very fast to begin with, but that of course
depends on the complexity of the instrument. Besides, theoretically
libinstpatch would be just as fast with the first note (1 preset
calculation done in both cases) and faster with any notes afterwards.
In practice, this probably just means less CPU consumed per note-on.
The way forward for adding this functionality into FluidSynth:
- Create a new SoundFont loader using the Swami plugin as a basis
(I'll contribute it as LGPL to FluidSynth, since its GPL in Swami).
- Add 24 bit sample support to the FluidSynth SoundFont loader API
- Probably some other things that aren't occurring to me at the moment
We must also change/rewrite the interpolation routines as well to handle
sample data of different sizes, right? That's where the actual data comes
in.
True. I think it makes the most sense to duplicate the existing
routines and adapt them to whatever format we decide on (rather than
trying to make them handle multiple formats). Using real 24 bit (3
byte) samples doesn't really make sense from a synthesis standpoint,
so I suggest we either go with 32 bit integers and/or floating point
audio.
So actually really not that much needs to be done. Since most of the
code is already there, just needs to be properly integrated into
FluidSynth as another loader option. Could even be made build time
optional. I'd be happy to do this work!
Contributions are welcome :-) But as you say, libInstPatch should probably
be a build time option. And we might want to split fluid_sample_t into an
fluid_rsample_t for the hard real-time side. It needs some design work.
Sounds good. It may be that we can do some minor changes though
(addition of a new sample format) without breaking the binary
compatibility of the API. Some analysis could then be done of the
existing limitations for future changes of the SoundFont loader.