Graeme Gerrard wrote:
> 

> Why not use the term function to refer to ...er... the function calls in
> the Csound orch and a generic term like statements to refer to everything
> else?

Well, yes, that is what they are, for a programmer's point of view, but
a Csound programmer could also write a mathematical function as part of
an instrument, so I don't think that will eliminate confusion.
The other classic term for a Csound opcode is 'Unit Generator', which is
explicit and unambiguous. Unfortunately, it is a bit of a mouthful, and
'UG' is little better.

Csound has been compared by some to a species of assembly language = the
mnemonic representation of the raw low-level instructions a processor
uses, and the 'opcode' term really arises from that analogy.

On the other hand, many of the instructions in a score file are really
directives to the score preprocessor (to reinterpret start times,
recalculate times with respect to tempo changes, and so on), so neither
'opcode' nor 'function' would be appropriate here - though the latter
does legitimately apply to GEN functions, of course.

My vote is to keep 'opcode' for the orchestra, and to refer as we do to
'GEN functions', 'score statement' or 'score directive' for preprocessor
instructions 't', 's', 'a' etc, and 'event' specially for 'i'
statements. The term 'event' is explicitly used in Cscore, for example,
for almost all the functions which write text to a score file. The only
problem with 'statement' is that it is so general that it covers
everything and distinguishes nothing.

This should minimize confusion for those new to Csound, and especially
those without a background in programming. Those active in other
disciplines will know that some of these terms can mean other things,
but hopefully that will not bother them at all!

Richard Dobson