Re: [fluid-dev] Fluidsynth changes

[Josh Green]

Having read over the responses of other users, I wanted to write a bit
more on my thoughts, since I think I was a bit hasty in my response to
Miguel concerning his changes.

I think the main thing that FluidSynth lacks currently is simply active
development.  The project has been barely limping along since I took
over the maintainer-ship.  It could really use, new ideas and a well
thought out direction.  For this reason I do very much appreciate the
efforts of Miguel.

I do believe though, that the very reason for FluidSynth's success, has
been its rather simple but clean C API.  If it was C++ only, I doubt it
would have seen the success it has today.  Perhaps a better solution
would be to look into providing a C++ binding to FluidSynth?  I would
like to know a little more about Miguel's motivation to move to C++.  In
reality C is still the least common denominator when it comes to APIs.

I think this is a good chance though, to define just what is wrong or
could be improved with current FluidSynth.  Having a better idea of
direction would help in making decisions about just what a FluidSynth
2.0 could be.  While it would be nice to have a unified effort in
improving FluidSynth, I don't see a problem with Miguel creating a
separate project if it fits more the vision of what he wants to work
with.

I've started a Wiki page which we can use to gather ideas and get a
general consensus of what FluidSynth 2.0 will be.  The rest of this
email is summarized there.

http://fluidsynth.resonance.org/trac/wiki/Future


Summarized on Wiki
------------------

I as a developer personally need a better overview of FluidSynth.  In
particular in regards to threading and mutual exclusion issues.  Its
hard to modify the code base when not familiar with what needs to be
mutex protected.

Many utility data types and portability stuff is built into FluidSynth
(the GList linked list code was ripped directly from glib for example).
This was done for the sake of portability, but I believe it also creates
a mess, since libraries such as glib were designed in the first place to
provide a portability layer, it seems silly to try and maintain the same
thing in FluidSynth.  I think the dependency of glib would not be a bad
one at all, but perhaps there are other portability platforms/libs that
would suit the task better.

New features and improvements:
- Streaming sample data via callback functions

- Other audio formats (floating point or 24 bit for example, new
SoundFont 2.04 supports 24 bit, and now Swami/libInstPatch does too, but
can only hear it in 16 bits!)

- Real synchronous stereo and multi-channel audio (i.e., voices in a
group can be guaranteed to start in the same FluidSynth buffer)

- Improved voice stealing

- Audio file output using libaudiofile

- MIDI file rendering in non-realtime (as fast as possible) with exact
event timing

- Look into adding features to make use of features of other sample
formats (DLS and GigaSampler for example)

- Overhauling SoundFont loader (its based on my really old code from
Smurf SoundFont Editor, which is now Swami).  Perhaps look into just
using libInstPatch directly.

- GStreamer plugin (already in the works)

- Synthesis verification and test suites.  I suspect many synthesis
issues, but there needs to be an easy way to verify the output and
analyze at a sample by sample basis.



As for the question of platform.  We have:

A. Continue using C without any support libraries
B. Use a portability/utility library such a glib but remain C
C. Use GObject which is also part of glib to be a little more OO but
also remain C (would get Python bindings rather easy too, in that case)
D. Move to C++ and look into writing a C binding

Of note is that A-C could indeed have a C++ binding.  I believe though,
that in order to best serve current FluidSynth users, it is in the
interest to continue with a C based API, and provide bindings for other
languages (C++, Python, etc).

I'm currently using GObject in Swami/libInstPatch.  At this point, I'm
not sure if that is a good idea to go that direction or not for
FluidSynth.  One nice thing about it is that there is already work done
in the area of auto generation of Python and C++ binding (PyGTK and
Gtkmm).  It does provide something more OO for C, but I'm not sure the
FluidSynth API would even really benefit from it.  I am highly in favor
of using glib as a dependency though.



Its exciting to have such a discussion.  Cheers!
        Josh Green