This is to the best of my understanding an exact description of Microsoft's COM mechanism
for Windows! It is awesomely complex, but it does seem to work remarkably well. It's
natural idiom is C++ (table of virtual functions), but it is defined as a 'binary'
standard, so that in principle, it is language-independent. Much of the complexity stems
from this (the rest stems form the need to suppot multitasking and multi-threaded
processes). However, is is intrinsically 'object-oriented', and would sit rather badly
with Csound's host of static and global variables, and tendency to do hard exits whenever
something goes wrong!

It sounds as if you have hit the happy balance between power and simplicity. I would be
very interested to have  a more technically detailed exposition of your methods in
GrainWave.

Richard Dobson


Mike Berry wrote:

> There is another way to go with the dynamic linking issue, and that is to
> approach it on a middle ground.  Instead of saying "Every existing opcode
> needs to be in a DLL", we could instead have a plug-in structure.  The plug-in
> has a single entry in entry.c, with an arbitrary number of optional inputs and
> outputs.  When the parser goes to check syntax, after it checks entry.c and
> does not find a match, then it checks the plug-in registry for a match.  All
> calls are then handled through the plug-in registry.  Only a few basic
> functions (like print to screen) are included in the plug-in API.  If you want
> to write an opcode which does more complex csound system calls, you write it
> the traditional way.
>         This would allow us to offload a number of the newer opcodes (like the phys.
> models) into plug-ins.  You can choose to have them or not.  Adding new
> plug-ins then does not require recompiling the entire source.  All of the
> basic opcodes could remain in the source.
>         Here is what I think would be required:
>
> 1.) A plug-in registry at startup which finds any available plug-ins.
> 2.) An insertion into the orc parser which checks the plug-in registry for
> opcode matches.
> 3.) An opcode called pluginregistry, which makes the connection to the proper
> piece of i, k, and/or a code.
>
>         I have a similar system in my program GrainWave.  A plug-in is almost nothing
> but the actual sound processing code.  This also means we can sidestep the
> thorny issues of what can and cannot be allowed to happen inside an opcode.
> We just set a limit.  If your opcode has to do something that is not allowed
> by the plug-in, then you fall back on the traditional way of adding an opcode.
> --
> Mike Berry
> mikeb@nmol.com
> http://www.nmol.com/users/mikeb