| On Fri, 5 Sep 1997, Jean Piche wrote:
> Mike Berry wrote:
>
> > Opcode bloat has certainly already hit csound hard
>
> good firecracker... more on that?
>
> --
If I interpret that correctly as a request for elucidation, then
here it is. (caveat: this comes from someone who wades around in the
code, for whom added opcodes is a sometimes tedious exercise).
I think that there are a number of opcodes which are largely
collections of other opcodes, or in which functionality has been largely
duplicated. Take the MIDI opcodes for example. We presently have a
different opcode for every kind of midi data, in some cases three opcodes
to retrieve the same data (cpsmidi, octmidi, pchmidi). Now we will also
have separate opcodes for 7 bit, 14 bit, and 21(?) bit controllers. Why
not just one single midi opcode? You could specify what type of data,
what resolution, and what scaling you wanted.
I know that for backward compatibility reasons no opcode is ever
removed from csound. But if we're talking about version 4.00 (I know you
didn't mention it jpff), perhaps some pruning is also in order. It
wouldn't be hard to make an orchestra converter which, for instance, went
through a pre-4.0 orch and changed all of the midi opcodes to a correct
instance of the single midi opcode I just proposed. It could just fill in
the assumed default values for things (like bit-range) which didn't
previously exist.
I mention this not just to keep entry.c from becoming 50000 lines
long, but because the proliferation of opcodes considered by itself does
not make csound easier to use. Yes there are valid opcodes still to be
written. I don't want to freeze csound at any point. But we should also
consider ways that the current opcode load could be reduced through
consolidation.
Mike Berry
mikeb@mills.edu
|