Re: Fwd: [fluid-dev] Fluidsynth changes

[Josh Green]

On Fri, 2007-04-20 at 19:42 +0200, Miguel Lobo wrote:
> Hi Josh,
> 
> Glad to hear you like the idea! 
> 

I like the general idea of doing some overhaul like activity :)  I'm not
completely sure at this point if C++/QMake is the best direction for
"FluidSynth" though.  I imagine its a platform you feel more comfortable
using.  I hope that whatever the decisions of FluidSynth development
are, that you find the best way to contribute your efforts and that it
can be mutually beneficial for the project.  When it comes down to it,
its really about who is willing to put in the time and effort to keep
FluidSynth going and *improving*.  If it means converting to C++ in
order to have more developer interest, I'd rather have that than a dead
FluidSynth project.  But keeping the existing application support base
is a must.  This means a C like API is of utmost importance (I voice
this also for my own project Swami).

>         There are some programs (such as my own software Swami) which
>         are C 
>         based and use FluidSynth.  I'm not apposed to moving
>         FluidSynth to C++
>         (the original author Peter Hanappe had also thought about
>         this), but I'd
>         like to investigate what options are available for keeping
>         some sort of 
>         interface to C based programs. 
> 
> Generating C bindings from C++ headers should be very easy; in fact,
> as I said in another message, I'm surprised that there are not a
> hundred C binding generators for C++ around the Internet (or at least
> I haven't found them).  If I don't find one such generator I'll write
> one myself, but I don't think that makes any sense until the C++ API
> itself is mostly finished.  In any case, a C binding to Fluidsynth is
> in my plans. 
> 

It would be good to evaluate better though, if having a C++ binding to
FluidSynth makes more sense than having the whole thing in C++.
Portability is a huge goal, and C++ sounds to be a bit less portable.  I
like the idea of FluidSynth being something that could be used in
embedded systems or even cell phones (think SoundFont based MIDI ring
tones).

> 
>         Swami does all its own instrument
>         management and loads instruments via the SoundFont loader API,
>         which 
>         makes it flexible enough to load other types of instrument
>         formats as
>         well (albeit with SoundFont centric parameters).  I've often
>         kicked
>         around the idea of using libInstPatch directly in FluidSynth
>         for adding 
>         instrument management for other formats, but decided this
>         wasn't
>         absolutely necessary, since libswami could itself be used for
>         that.  It
>         might be interesting to revisit this idea though.
> 
> I had actually thought about that myself, but obviously you are the
> best suited to determine how complex a change that would be (versus
> just copying the soundfont loading code from libInstPatch and adapting
> it to FluidSynth needs). 
> 

As libInstPatch gets more stable API wise, I'm getting more tempted to
just convert FluidSynth to using it.  There is no reason why FluidSynth
users shouldn't benefit from the synthesis of other instrument formats.
It could at least be a optional compile time option at first, with a
fallback on the existing loader.

> 
>         I'm not very familiar with QMake myself.  I'd need to do some
>         more 
>         research to get a better idea if it seems to fit well with the
>         project.
>         What other projects are using QMake, besides QT based
>         applications?  I
>         hope the install of QMake doesn't necessitate the installation
>         of QT4.
> 
> QMake probably shouldn't need the Qt4 runtime, since it's used to
> build Qt itself without any of the Qt libraries available yet.   But
> anyway, surely installing Qt4 shouldn't be a big problem these days? 
> 

Well, since FluidSynth isn't GUI based to begin with, its not a very
good idea to have it as a dependency.  I know of one blind Linux user in
particular who would be very upset.  Embedded systems developers
probably wouldn't be too happy about it either.  And an even bigger
question, what is wrong with current automake/autoconf?  If there is
something wrong with it, is it better to switch to something else or fix
the problems with it.


> 
> I think if anything writing in C++ will make it easier to write
> bindings for other languages, since those other languages are usually
> object-oriented nowadays and their concepts are closer to C++ than to
> C. 
> 

That isn't necessarily true, since many scripting languages (such as
Python) are in fact C based underneath.

> 
> Anyway, I hope you're not averse to learning enough C++ to contribute
> to a C++-ized FluidSynth!  I think that should be fairly easy for an
> experienced programmer, and of course there's plenty of help available
> in the Internet, including (modestly) myself. 
> 

If it was decided that FluidSynth should move to C++, I would follow
along and help where I could.  I'm not completely ignorant to C++, I
just find that C often gets the job done just fine.  I would like to
hear a little more about your intentions with converting FluidSynth to C
++.  I do have a good understanding that this is the world of free
software, and many of us program because we like to.  So I'm not asking
for justifications, I'm more just curious if perhaps the FluidSynth
project could still benefit from your efforts, even if its decided not
to use C++.  Perhaps a C++ binding would be satisfactory?

> Regards,
> Miguel
> 

Cheers!
        Josh