| I think the strong point of Csound is that it is NOT object-oriented.
You do not want to have to deal with the higher-level concepts of
someone else telling you what an instrument is supposed to be. For
Csound the result seems to be an active community of users and regular
additions of new opcodes from among those users. And, like someone
remarked, even if it is like assembler, what's wrong with that? It is
nice to have a language in which you can tweak things without being
bothered by classes or what have you.
My main complaint would be about the score language, which seems to view
a score is a series of events ordered in time. Some MIDI sequencers let
you do interesting things with repeating patterns, which could be of
different length (Logic Notator lets you do that, for example). Have
others felt those limitations and found a solution?
Job van Zuijlen
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.
>
> 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). I have no idea what it
> would look like, I only have a strong gut feeling that the language of
> CSound could do with a major revamp.
>
> I'm just brainstorming right now: first the new language would have to
> be designed, based on object-oriented design principles. Then, in a
> first phase) a preprocessor built which translates the new language
> into CSound orc/sco's (maybe in Perl). Then you invoke the CSound
> compiler. Later the preprocessor and the compiler could be integrated
> into one program.
>
> No, it will not improve the speed. And of course, I don't have the
> time to do it myself, and even if I had it, I'm afraid I'm not smart
> enough.
>
> Koen Dejonghe |