Well, I would say that the decision has not yet been made. I am leaning
towards continuing to use C, but I don't feel that it has really been
very well weighed out yet. The biggest issue is once again, who is
willing to program on FluidSynth. I'm not completely convinced that C++
is necessarily a good idea to improve the code base, but if it means
more developers being interested, then why not?
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.
Your priorities seem to be in using C++ and QMake.
I don't really care about the build system as long as it fulfills these requirements:
- Easy to use for somebody who just wants to compile the project without knowing much about it.
- Simple and painless to maintain.
- 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).
I think the FluidSynth project needs to make it a priority to continue providing a
simple API and other interfaces to other applications.
Agreed. Simplifying the API is in fact one of my top goals. You may note that Qt, a C++ library, has been widely praised for the clarity and ease of use of its API. If we could only get FluidSynth's (or my project's) API to be half as well designed as Qt's, I'd be ecstatic.
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.
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.
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.
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:
- Any C compilers you're likely to use (i.e
. MSVC or GCC) are also C++ compilers.
- 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).
- 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).
- Using templates and inline functions, you can replace those convoluted C macros with debuggable, readable, type-safe code, without losing performance.
- 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.
- 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.
- 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.
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.
[...] 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.
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.