Hi Josh,
Its unfortunate that C and C++ have to be so divided in the world of
programming.
I agree, especially since C++ is 99% a superset of C and all the new features are completely optional.
In the past the ABI unstability and incompatibility was a real problem for C++ (although IMO much more was made of it than it really warranted), but nowadays there are no real problems I can see with C++ development vs. C development, and I say this as a person who was done a fair bit of both.
No I don't particularly mind announcements of a forked
FluidSynth, as you do seem set on continuing with the platform as you
have it. While QMake/C++ might fit your needs, it likely doesn't fit
the needs of many other users.
While I respect that point of view, I honestly don't understand why it wouldn't. Let me clarify anyway that QMake is (currently) a build dependency and it will never be a runtime dependency. I also like my projects to be as free from external runtime dependencies as reasonably possible.
There were recent updates in CVS that fixed a number of issues with the
loader (mainly memory leaks). The SoundFont loader is just somewhat of
a hack in my opinion (so my comment is more related to the quality of
the code). It was kind of forced into the FluidSynth code base from a
separate project. It wastes a bit of memory in its current
implementation, from what I have seen. My main motivation to using
libInstPatch in FluidSynth though is to be able to use other instrument
formats as support is added in libInstPatch.
Ok, thanks. I don't know to which degree libInstPatch makes other instrument formats look like SoundFonts, but if the "abstract" libInstPatch instrument looks very different from a SoundFont's, kaing FluidSynth use it will be a big job IMO.