[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] callbacks

From: David Henningsson
Subject: Re: [fluid-dev] callbacks
Date: Mon, 22 Nov 2010 09:26:43 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Thunderbird/3.1.6

On 2010-11-15 04:17, Element Green wrote:
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.

Ok, if it the same calculations being done on every noteon, there's no doubt we should have it.

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

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

It would be interesting trying to SIMD:ize them as well, but it's not trivial. The output is fluid_real_t, perhaps we should see if there is any speed difference between having the input as 32 bit integer or 32 bit float.

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.

I admit I'm a little rookie when it comes to these things. Keeping the API backwards compatible shouldn't be that much of a problem, should it? And as long as we don't change functions into macros or the other way around, the ABI should be backwards compatible too? And even if it isn't, is there a problem with breaking the ABI between versions?

// David

reply via email to

[Prev in Thread] Current Thread [Next in Thread]