| For the Csound list folk that have not seen this: it is a disscussion I
am having with the bright and
amazing Dave Phillips on why I try not to use his (otherwise excellent)
linux "version"
of Csound, and stick as much as I can to the jpff bath version, even
though the bath binary does not have real-time MIDI on my system.
Since I think this is an important issue for the entire community, I
forward this disscussion to the
csound list proper. I hope Dave forgives me :).
Dave (quite reasonably) asks:
>Charlie, I'm curious why you would rather use John's binary. Feel free
>to correspond directly, I'm not flaming but I would like to know what
>you think is "incorrect" in the developers version.
Dave,
Since I hope you understand that I mean no flame at all to you or *any*
member of the
linux csound group, i therefore respond in public, I hope this is all
right!
I wonder if you have direct experience in supporting a large complex
application directly?
In the sense of being directly responsible for bug fixes and changes
discovered by a large
active user base? I'm sure we all have some experience with the
difficulties of code base
maintainance. And as good as our intentions in the linux community, I
fear we are making
jpff's job near un-do-able, rather than contributing to the code base. I
agree that there are
*many* things we should/could do to fix Csound. But if this means
creating yet another line of
code history, we are only causing problems.
I want to get beyond the point where half the questions in the csound
list have to be immediately
responded to with "What platform and version are you on?". i see John's
efforts as invaluable in
giving us a core "product". He publishes bug fixes. We add "new
functionality". I know which of these
two seem "cooler". I also know which one builds a solid app. Not that we
shouldn't couldn't try to
expand Csound. But imagine this scenario: dp,rb, etc. have a solid and
useful piece of code, in the
linux MIDI stuff. They get together, and *SUGGEST* the patch in Csound.
jpff considers, finds
incompatibility, reluctantly refuses: dp/rb/etc. jump into action,
retro-fit the fix to the orig. API,
or port all other OS dependant code to their API. (Hey, sometimes, it's
easy...if not..well...)
jpff is overjoyed at MIDI overhaul, releases new Csound, to much
rejoycing. OR
disgruntled linux hackers leave to contribute to quasimodo (which I
think is smarter for those wanting
cool new stuff like OOP, dyn.libs, etc.).
Advantages: Slow controlled growth to Csound. Better bug control. Better
community knowlege base
and we won't be spending half our time going: "Oh!! You're on RH4.0!!
You need *this* specific
source tree, or it won't work!!"
Now , if this was a one/two person in-house project,
then those two can merge code easily. BUT IT ISN'T. WE NEED A "TREE
MEISTER", AND I THOUGHT
JPFF WAS IT. IF YOU WANT TO REWRITE CSOUND, START WITH HIS CODE, AND
SUBMIT THE
RESULTS TO HIM FOR POSSIBLE INCLUSION.
Now I know this really grates on some programmers. If you're one, go
off, and hack the Csound code into
whatever shape you want to. Just on't call it Csound, and don't rely on
(and burden) the same support
network as the users of the standard code base, ok?
Just some thoughts from a grumpy old programmer......
and really, no personal animosity at all!! PLEASE understand, I mean
only the best. Really!!
You guys are great. I just want the team to row in synchrony.
Pax,
char lieB
--
Charles Baker - baker@charlieb.com - http://www.charlieb.com
6.44 It is not *how* things are in the world
that is mystical, but *that* it exists.
L. Wittgenstein Tractatus-Logico-Philosophicus
|