Some months ago I remember a discussion about limiting the
addition of opcodes to avoid the explosion of entry.c and to keep
the sources manageable.

Now that practically all systems support dynamic library loading
(yes I know there is still DOS, but we could consider a work-around for that),
maybe a solution could be to distribute the opcodes in several
dynamic libraries (libxxx.so under linux, .dlls under Win95, etc.)
and these libraries could loaded dynamically (w/ dlopen(),dlclose() calls)
as requested by the orcs. The entry table could be substituted by
a linked list of tables (one for each library) and perhaps a configuration
file to define loading paths and priorities.

This could have a number of advantages:

1) better structuring of opcode code
2) smaller in-core runtime executables when few opcodes are requested
   (which, paradoxically, could help real-time)
3) opcode libraries could be maintained separately
   by different groups, with better sharing of workload 
4) even if I personally do not like the approach at all, some libraries
   could be distributed in binary form only when the author(s) do
   not feel like distributing the sources (think, for example, about
   the famous ambisonic opcode which cannot exist for patent problems...)

The disadvantages are obvious but need some consideration:

1) system is slower (even if it could be argued that it would only be
   slower in orchestra loading and not during play)

2) the package requires some quite thorough definition of how to
   build libraries, how to call them, etc. otherwise everything is bound
   to end up in chaos

I am willing to help in this endeavour if there is a general agreement
that this thing is useful.

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.