You have forgotten one very important aspect: Before one can
contribute in terms of code; compile errors, runtime errors, bugs,
critical performance bottlenecks, maintenance problems, etc. have to
be identified. A program/app is only as good as its performance in
the real world. This feedback can only come from the end-users who
are after all, the people for whom the program is written for. In
addition, feature requests in most cases come from users who need
certain features to ease their workflow. In other words, the end
user- coder relationship is of capital importance. If the fanciest
algorithms do not enhance ease of use or make any detectable
performance improvement, what's the use?
Three points:
- Users of an OSS project are not necessarily what is known as "end users" i.e. people who only want to run an application and have no interest in how it is coded. In particular, the users I'm thinking of for my project are OSS coders who need an embeddable synthesizer for their own projects. I hope that by providing a smaller, more powerful, easier-to-use API, they will be better served.
- Speaking generally, it is quite possible that the existing users of a project will not demand or see the need of a certain major feature, and yet that feature, when implemented, may bring many new users to whom the project was useless before because it lacked that very feature. As the feature set of the project changes with time, so will its audience.
- This is OSS. I'm a volunteer. I code because it's fun, not because I'm paid or because I hope to satisfy the expectations of certain people. I do hope that others will find my work useful, but if not even one person is interested in my code, or if for lack of time or interest I never finish my project, does it mean my project will have been a waste? Not in my eyes. I will have had fun while coding it, and (hopefully) I will have learned something.
Fair enough. My one criticism for your proposition is that I cannot
see how changing the code base from C to C++ will help when using the
program.
Hopefully it will now be clear that the "use" I'm thinking of is actually of the libraries, by other coders, rather than by end users.
Have you also considered how code transparency might be affected?
Don't know what that means. If you mean ease of use of the API, then yes, I hope it will be improved.
At the moment, it looks like you want to re-invent the
wheel because you have certain coding preferences?
In past mails I have tried to explain my technical motivations, and certainly I don't think yours is a fair summary. I may have failed in explaining myself, but at the moment I'm not interested in trying again.
What would the advantage of MSVC compatibility be for OSS? Is MSVC
freely available?
You can use certain versions of MSVC free of cost, which is what I'm doing.
On which OSes can MSVC be used?
On the ones with 90%+ of the user base?
Autotools are freely available and work on a multitude of OSes
including all the Linux flavors and UNIX OSes.
I actually knew that. On the other hand, many of those OSes won't be able to use Fluidsynth as long as it lacks an audio driver compatible with them. Fluidsynth has a Windows audio driver. Does it have one for Solaris? No? Then what use is a build system that supports Solaris?
Right, no offence meant.
Excellent. Sometimes people seem to forget that we are supposed to be doing this for fun.
To my knowledge, C++ is a superset of C so I would imagine that any
code enhancements that you propose could easily be "translated" to C
if all the objects, containers, methods etc. are clearly defined. If
you know C++ very well, the transition to C in theory would be rather
effortless.
C++'s features are useful precisely because they can't be simulated in C that easily. But anyway, I won't be doing that translation; good luck to those who will.