I agree that SAOL is probably the closest to what you are describing, though I
suspect it's still a way from being an object-oriented language in terms of such
things as inheritance and polymorphism. Smalltalk is another obvious language,
which is fairly widely used for computer music. None of these is Csound however,
which is expressly a 'low-level' language, indeed emulating assembler...

Koen Dejonghe wrote:
> 
> Richard,
> 
> I am sorry if I was unclear. I really meant the orc/sco code. I have
> not seen the source code to build CSound yet, I downloaded a
> pre-compiled version, and I'm (almost) happy with it.
> 
> The first time I saw CSound "programs" (read orc/sco files) I couldn't
> help thinking that this looked a lot like the assembly language used a
> thousand years ago.

...which is of course still very much being used! There are also plenty
advocating FORTH as a language for computer music - compact, expressive,
powerful, but not object-oriented. Appropriateness for the task seems to end up
being much more important to composers than how old or fashionable the language
is. 

In OOP, the emphasis tends to be on the management of medium to large projects,
in which months, if not years, may be spent on design, before any code is even
written (well, that's the theory, anyway). Most Csound instruments and
orchestras tend to be, by programming standards, fairly small objects, developed
incrementally, for which a full object-oriented language is arguably overkill. 

At the compositional level, where abstractions are particularly important, OOP
and functional languages (Smalltalk, lisp,nyquist etc) are widely used. The
output from these might well be a Csound orchestra and score - Csound represents
a viable low-level language for this task, while still being (relatively)
readable. 

I am not up to date with the literature, but my impression is that a wide
variety of custom 'front-ends' or preprocessors have been designed, to create
both instruments and scores (though the emphasis has tended towards the latter).
And I think Jean_Claude Risset still uses MUSIC-V!

 
> What I meant was that an object-oriented version of the CSound
> language would be great. Imagine base classes of instruments (the
> score being a member of the instrument) that you can re-use,
> inheriting all of its components, but adding or changing some
> parameters here and there (e.g. the score).

This would be perhaps even less object-oriented than Csound! If the score is a
member of the instrument, strictly speaking it would be 'private'; at the very
least, the coupling between the instrument and the score will be very tight,
which is one of the things OOP programming strives to avoid - change the format
of the score, and all the instruments have to be changed too. Rather, the score
'object' would send the instrument a message 'play this' - which, funnily
enough, is more-or-less what happens already. There is coupling, of course - the
pfields are in effect the 'public' variables of the instrument, so that it is
all but impossible for all scores to be playable by all instruments. Csound
composers rely on this low-level control and compact notation. 

However, the design of languages for synthesis and composition is still a huge
research topic; there is plenty of room for new ideas, and if you can put more
detail to yours, there may well be programmers on this list, and elsewhere, who
would be interested to implement them.