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.
That seems like a fair description to me.
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.
Definitely. As I mentioned, that name was just meant as a joke and I hope nobody took it in any other way. In fact, I have already renamed the fork to something else completely Fluidsynth-unrelated.
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.
As I said, no hard feelings on my part at all. If anything, I would like Fluidsynth and my project to be "sibling projects" and to have as much collaboration going on as possible.
I foresee this collaboration taking the form of a mutual gentlemen's pact to explain to the coder(s) the other project, when they ask, why a given improvement or change was made and to provide them with as much information as they need to incorporate that improvement into their project if they so wish.
I must repeat that I'm very grateful to past and present Fluidsynth coders and harbor no ill will at all to anybody, even those who most vehemently opposed the C++-ification. I do believe that everybody is entitled to their own opinions.
> 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.
Well, I would say that it is more fact-based than just "preference".
Discussions are usually a major part of people working together on a
project though.
I understand that, but the discussion/actual work ratio can only get so high before one feels there's too much of the former and not enough of the latter. After all, I work on OSS projects because I enjoy the coding, not because I enjoy the discussions.
I question how many of those features could really benefit FluidSynth
though.
I thought so ;).
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.
From that point of view, the C++-ification certainly wouldn't help much with those goals.
Sounds like a good plan.
Well, I'm not sure now. It seems you have a clear vision for Fluidsynth now and that vision seems incompatible with my own. I will made of course my code public when (and if) it's ready, but I doubt Fluidsynth is going to be much influenced by that.
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.
I know glib. In fact I programmed a little bit with GObject some years ago. Suffice to say, I didn't like it.
Just curious: are you planning to GObject-ify Fluidsynth? It seems to me that would be as much work as the C++ translation.
Kind regards,
Miguel