I'm entirely sympathetic to your criticism that I'm trying to redesign the
code, but (very painful and extensive) experience warns me that trying to
make the code more truly platform-independent without redesigning it is not
likely to work very well. It just becomes more and more of a hodge-podge
until trying to fix one thing invariably breaks another thing... these
nested #ifdefs are entirely out of control... believe me, I also know how
much work and pain is involved in redesigning something as complex as
Csound. A good part of my professional life, my day job as a programmer, has
been involved with maintaining old code, porting it from one platform to
another, and adapting it. I've been down both branches of the choice here to
the tune of thousands of hours and hundreds of thousands of lines of code.
Some of this work has been on Unix, and some on Windows (but none on the
Mac). So, I have some real experience here.

As I've said before, if this redesign is not done and done well, then Csound
will be replaced as a de facto serious software synthesis standard by
something else, such as an efficient implementation of SAOL, or a
cross-platform SuperCollider, or something like Reaktor, or something not
yet imagined. If it is done and done well, then the weight of all the great,
working instrument definitions, scores, and orchestras will keep Csound
alive and a contender for years if not decades to come.

In other words, the real value in Csound is what has been written in the
Csound languages, not the C code that implements those languages.

I've followed Quasimodo, but I'm Windows based while it is Linux based, and
I haven't yet and may never take the time to see if I could adapt it as a
newer cross-platform implementation of the Csound languages.


-----Original Message-----
From: Larry Troxler 
To: Michael Gogins 
Cc: Dave Phillips ; Csound Mail ;
Adam Zygmunt ; Jason ? 
Date: Monday, August 09, 1999 9:12 PM
Subject: Re: compiling Linux Csound (official)


>Michael Gogins wrote:
>>
>> I second the motion for platform-specific MIDI files.
>
>I agree, that in that it is better to sepearate out the platform
>specifics into a few (few as possible!) source files, then provide
>platform specific versions of those filess.
>
>
>MG again:
>>It could be done as
>> follows.
>
>
>Arggh! What are you suggesting? I suppose you are volunteering to
>implement this change, test it, and submit it to John Fitch?
>
>There is no need to change the design at all. Usually, when you have
>platform specific source files, they simply provide a common set of
>global functions. This could in fact, as a first draft, be done almost
>mechanically by generating the platform-specific files from
>pre-pre-processed (!) versions of the original multi-platform filee. I
>totally don't understand the reason for your proposal, unless it is to
>clean up the code and redesign it, in which case, IMO, that goal is
>orthogonal to the problem at hand.
>
>Larry
>

im sorry if i lost a bit upstream on this thread..
(im also sorry for mixing metaphors)

> I'm entirely sympathetic to your criticism that I'm trying to redesign the
> code, but (very painful and extensive) experience warns me that trying to

> something else, such as an efficient implementation of SAOL, or a

i dont exactly what you are doing, but if its "slash and burn"
redesign of csound then why not focus energies on making SAOL?
 (and why havent you quit your day job?)

-m