Re: [fluid-dev] callbacks

[Element Green]

On Mon, Nov 22, 2010 at 12:26 AM, David Henningsson <address@hidden> wrote:
>> 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.
>
> 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.
>

I think this was also an area that Markus Nentwig explored.  The
conclusion, I think, was that there was no real benefit from 32 bit
integer math, in fact I think it was slower (which makes sense,
because floating point instructions can be executed in parallel with
integer instructions).  I do however see a benefit in providing a
completely integer based synth, for the case of embedding on a system
without an FPU.  But I think this would be a lot of work, for a rather
niche use.  There are plenty of embedded systems with FPUs these days.

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

I'm also not an expert concerning what can be changed without breaking
an API.  I think fields can be added to structures, so long as the
allocation is handled by the library.  I imagine if we come up with a
substantially different API for the SoundFont loader, the old one
could still remain in parallel with it (new functions, etc for the new
API).

> // David
>

Element