Re: [fluid-dev] Fluidsynth changes

[Josh Green]

On Sat, 2007-04-21 at 21:13 +0200, Miguel Lobo wrote:

> Oh, my understanding from yesterday's discussion was that the decision
> had indeed been made.  The belief in maintaining the statu quo seemed
> fairly strong around the list. 

It didn't really seem like a decision was made to me, it was just that
the overall consensus seemed to indicate that continuing to support
existing FluidSynth users is important.  It sounds to me like you would
like to have your own FluidSynth based project which is coded in the way
that you would like.  I don't have a problem with this and perhaps it
makes the most sense to start your own fork.  I would appreciate if you
don't call it something like "Next Generation FluidSynth" though, that
seems a bit like a kick in the face to FluidSynth.

> I don't really care about the build system as long as it fulfills
> these requirements:
>      1. Easy to use for somebody who just wants to compile the project
>         without knowing much about it.
>      2. Simple and painless to maintain. 
>      3. Fully featured Support for MSVC under Windows without the need
>         for a Unix-like environment (be it Cygwin or MSYS).  Missing
>         features like header dependency tracking and similar for MSVC
>         is not acceptable.
> I was able to use QMake to create a build system that meets these
> requirements acceptably in half an hour or so.  If anyone finds a
> better solution, that's cool.  Correct me if I'm wrong, but I don't
> think autotools meets 3 (and I have my doubts about 2). 
> 

Not sure I can comment too much on 3, since I'm not very familiar with
MSVC.  Most users building software on Unix systems are very very
familiar with autoconf/automake, not that it isn't without its faults.
As for maintaining the build system, that's really not an issue at all,
since very little changes are ever needed.


> 
>         By forking the project, you'll end up needing to merge any
>         improvements that are made 
>         to FluidSynth and vice versa and it may in fact be much more
>         complicated
>         to have contributions be mutually beneficial.
> 
> That's the trouble with forks, isn't it?  Nevertheless I don't think
> it would be so difficult for me to merge Fluidsynth improvements as
> they happen, although I might be totally wrong about this. 
> 

Not sure, I think most of this comes down to the attitude between the
developers of the 2 projects.  It would be nice to feel like any
particular forks of FluidSynth can somehow benefit the core project in
return.

> 
>         If the effort was instead
>         put toward making a strong C based FluidSynth core and
>         providing a C++ 
>         binding, it might provide for the functionality you are
>         looking for and
>         provide for more cooperation together.
> 
> I'm not really interested in this option, because what I'm looking for
> at this point is not to have a synth I can use from C++ (in fact I'm
> not planning on using it from C++ at the moment), but to have a synth
> that I can easily review, debug and improve.  Things like type safety,
> code clarity and brevity are important to this end, and I don't really
> think C OOP can provide them to my satisfaction. 
> 

Ok, so its really a matter of your personal preference.

> 
>         If you have any ideas/points to
>         offer about how FluidSynth will be improved by moving to C++,
>         I'd love 
>         to hear it.  Because as I have said, it may indeed be a good
>         idea for a
>         C++ FluidSynth with a C API, it just takes a little
>         convincing..
> 
> 
> To be honest, normally I don't really like trying to convince people
> of the sensibility of my technical opinions.  In my experience, much
> effort is usually needed for little result.  I'd rather spend that
> time coding. 
> 

Discussions are usually a major part of people working together on a
project though.  I think at this point I agree that in order to fulfill
your personal needs with FluidSynth you should indeed start your own
fork.

> However, since you asked, I think using C++ over C is a no-brainer
> these days (except in special cases like system or embedded software
> and so on), because:
>      1. Any C compilers you're likely to use (i.e . MSVC or GCC) are
>         also C++ compilers.
>      2. Your C program is a C++ program too with only *very minor*
>         changes needed (mostly renaming identifiers which are reserved
>         words in C++ but not in C).
>      3. The biggest secret in C++: if you don't feel the need to use
>         any given C++ feature, you *don't have to*.  I spent years
>         programming in C++ before I started using templates (back then
>         templates were not that well supported by the compilers
>         anyway).
>      4. Using templates and inline functions, you can replace those
>         convoluted C macros with debuggable, readable, type-safe code,
>         without losing performance.
>      5. C++'s OOP features really allow you to cut down on explicit
>         casts, which are non-type safe and generally a pain every time
>         you want to change the data type of something.
>      6. You don't like the standard C++ library or the standard
>         template library (STL)?  You don't have to use them.  I plan
>         on using neither in my FluidSynth fork.
>      7. Using C libraries from C++ is trivial, and generating C
>         bindings to C++ code is fairly easy too.
> In short, C++ gives you everything C does, plus a number of *optional*
> but *very useful* features.
> 

I question how many of those features could really benefit FluidSynth
though.  It seems to me like the biggest issues with FluidSynth
currently is adding new features and improving synthesis output.  The
API is rather usable as is, although I agree it could use some cleanup
and most of all, better documentation.

> Anyway, I believe in the usefulness of the "show me the code" approach
> in these situations.  Many people have strong opinions on some
> technical issues, but not so many are usually willing to translate
> those opinions into actual working code.  If you're not planning to
> start adding new features to FluidSynth right now, perhaps you'd
> prefer to wait until I've finished my C++-ification and then give the
> code a look to see what you think. 
> 

Sounds like a good plan.


>         [...] So it would be fairly trivial to switch
>         FluidSynth to using libInstPatch, since the code is mostly all
>         there. 
>         Its really just a question of where the code resides.  In some
>         ways I
>         think it makes a lot of sense to add libInstPatch support to
>         FluidSynth,
>         since the host of other applications would also then benefit
>         from
>         additional formats and it could at this point be optional.
> 
> I also think that FluidSynth should support as many instrument formats
> as possible and in fact something I'd like to have at some point is
> the ability to load instruments from the traditional soundtrackers
> (such as Impulse Tracker, FastTracker and so on).  However, IIRC
> libInstPatch depends on GLIB, right?  If so I would indeed like to
> maintain independence between FluidSynth and libInstPatch i.e. only
> use libInstPatch data types and methods from a well-defined and
> separate set of FluidSynth source files.
> 

Well, I'm considering making FluidSynth itself dependent on glib.  This
small utility library (not to be confused with glibc, which I'm sure you
are aware of) is a rather minor dependency and helps improve cross
platform compatibility.

> 
>         The synthesis model of SoundFont files is fixed of course (2
>         envelopes,
>         2 oscillators, low pass filter, reverb/chorus etc), but a lot
>         of other
>         formats can be modeled fairly well using the SoundFont model
>         (DLS for
>         example).  GigaSampler can also be of course converted to the
>         SoundFont
>         model, although there are certain specialized features that
>         can't
>         currently be done with FluidSynth (other types of filters,
>         random sample 
>         selection, etc).  A lot of this can be emulated with
>         modulators I
>         imagine though (cross fading for example) and I think it would
>         be a good
>         idea to look into adding some of these additional features to
>         FluidSynth.
> 
> That sounds great. I'm no soundfont or sound synthesis expert though
> so I'll leave that to someone else.
> 
> 
> Regards,
> Miguel

Best regards,
        Josh