On Saturday 11 March 2006 04:26, Anthony Kozar wrote:

> I do not care whether the functionality is kept or not.  (But I do wonder
> how it is implemented -- I haven't look at the code yet.  If the file
> opcodes.dir has to be maintained, then it might be awkward).

There is not really any other way to know which opcodes are contained in 
a particular library. If the library needs to be loaded to find out the
list of opcodes, that makes the whole idea pointless as the goal was to
avoid loading the plugins in the first place.

> In general though, I do not agree with the philosophy of merging most
> opcodes into a single plugin.  That was fine for the 5.00 release, but I
> would hope that new opcodes from now on will be added to new libraries
> (unless they fit into an existing group).  Since it is jpff's intention to
> add more opcodes to the barmodel library, I hope that it will stay separate.
> 
> My reasoning is that that is the purpose of having plugins in the first
> place -- modularity.  It would certainly run faster if everything was merged
> back into Csound5Lib, but I like the flexibility of multiple libraries.  I
> also think that it could be confusing if the contents of "old" libraries
> change too much.

In other words, merging libraries benefits the majority of users who do not
fiddle with deleting separate plugin libraries by hand, and do not want to
worry about not being able to compile an orchestra that contains opcodes that
were previously considered unimportant and were deleted. Without deferred
loading, very few users would bother selecting plugins manually for a small
reduction in memory usage and start-up time, yet a single large library loads
faster and uses less memory than the several dozen small ones it replaces.
It also means fewer build targets and fewer files in the binary distributions.
Also, the stdopcod library is very small by modern standards: with a typical
computer that has 512 MB of memory, it only uses about 0.1% of the total
available space (anything with external dependencies, like the python opcodes,
is likely to be larger). It does not really make much sense to have a seprate
DLL for something that has only about 2K of useful code (like the new barmodel
plugin) when the overhead of library headers, startup code, page alignment,
etc. is already larger than that.

Plugins are really mostly useful to have third party modules that are
distributed separately from the canonical package, but so far that was not
taken advantage of at all, as everything just ended up in the csound5 CVS
anyway.
The other advantage is to separate functionality with external dependencies
(e.g. FLTK or Python) so that if the dependency is not found at run-time, that
will not prevent the rest from working. That is why the stdopcod library only
contains code with no dependencies (that includes the standard C++ library)
other than what is already required by the main library.