"Marc Resibois"  writes:
> I would defy anyone that has looked to the code and tried to do something
> with it to think more than five minutesabout moving it to C++... I surely
> wouldn't.

You're not kidding.  CSOUND has to be one of the ugliest (sorry)
pieces of old-style C code I've ever seen.  A port to C++ would really
be cleaning the Augean stables.  Plus, I don't think it's necessary
because the object-orientation of C++ would be lost on CSOUND.
There's really no underlying object paradigm which applies here, it's
straight procedural: (1) read/parse .orc & .sco (2) generate output
(3) write it out.  

Of course, if you want to consider every instrument as an object,
score events as objects, etc. etc. a la Interviews where every text
character typed in the word processor is an object, please do so.
However, Interviews took great pains to avoid the computation overhead
of object orientation by implementing what they called "flyweight
objects", i.e. objects with mostly superclass inhertiance, as I
understand.  

This is a job for the CS geeks I think, not poor hackers.

Alexander G. Burchell
http://www.pacificnet.net/~agb/
agb@pacificnet.net

On Fri, 14 Feb 1997, Alexander G. Burchell wrote:
> 
> Of course, if you want to consider every instrument as an object,

Well, most definitely every *ugen* would be an object. That would be a
natural application of C++ classes.

Larry


--  Larry Troxler  --  lt@westnet.com  --  Patterson, NY USA  --
  

Well I've been watching this thread for several days and have tried to
resist adding my own two cents. But I feel compelled to add my own view at
this point, which is nothing more than probably common observations. 

First: Yes there are things that can be modernized and cleaned up in the
Csound code. Some of us have been gradually doing this and as the code is
widely available and free, anyone else can do the same.

Second: A point that seems to have been missed about the underlying
structure of the Csound code is that it IS in fact VERY object oriented in
design. One only has to build their own unit generators that use the
functions supplied by Csound to see how this is so.  Every new unit
generator is in fact a sort of "object" of the "class"  unit-generator
which includes "for free" a bounty of functionality that need not be
re-coded for each new unit generator. And this makes it VERY easy to add
ones own units to the language. So while it might not be OOP in the exact
and proper sense of using an OO language and syntax, the structure does
allow one to think in OO terms.

Third: I'm not against having someone rewrite Csound in whatever language
they feel would be the fastest and most effective. Just let us know when
you've got something that works as well or better than the current Csound
and I'll be among the first to try it out. Really.  But for the time
being, we've got something that really works, that is style neutral, that
is extensible, that is cross-platform, that is FREE, that comes with ALL
of the code!! It's really quite a miracle actually by the commercial
software standards of today. Remember (I know that such reminders have
already been posted, but I feel that it can't hurt to say it one more
time), Csound is FREE and is maintained, updated, and so on, by people
giving their own unpaid time to this project.

So let's stop commenting  about *ugly* code unless such comments are
accompanied by specific changes that could/should be made to enhance
the language for the community of users.

End of my two cents!


Richard Karpen

=====================================================
 Professor Richard Karpen
 Director, Center for Advanced Research Technology
	in the Arts and Humanities (CARTAH)
 Box 353680
 University of Washington
 Seattle, WA 98195

 Phone: (206) 543-7130  FAX: (206) 685-9499
 email: karpen@u.washington.edu
 www:   http://weber.u.washington.edu/~karpen
=====================================================