Hi All,

In a discussion with Victor, we came to the conclusion that the
problem affecting pvsosc not being recognized unless pvsinit was used
before hand wasn't a parser issue but ultimately an issue with the
deferred plugin loading code. I also realized too that the deferred
plugin loading code was what made it impossible for me to combine the
virtual keyboard into the widgets library.

We both came to the conclusion that the deferred plugin loading needs
a bit of review.  The plugin loading code works by loading the
opcodes.dir file (found in the root of csound5 CVS) which is a
formatted text file that describes what opcodes are found in what
libraries.  If an opcode library is found but an entry is not in the
opcodes.dir, then there is no problem and I think all libraries end up
getting loaded until the opcode is found and fails if not found in any
of the libraries.  However, if an opcode is added to a library listed
in opcodes.dir but that entry isn't updated in that file, problems
will arise as Victor experienced where the opcode won't be tested
within the library.

The other problem is that if an opcode library has a listing in the
opcodes.dir but if it is desired that csoundModuleInit be run
regardless of if any opcodes are used (as was the case for me and the
virtual keyboard driver), that won't work.

Now, if opcodes.dir isn't found, Csound currently just loads all the
libraries it finds rather than deferring that.  I don't know if the
installers on all platforms currently install the opcodes.dir file or
not, but if not, that is probably what made it very difficult to
figure out the bug that Victor and I each had.

So, currently it seems there are two things to discuss.  The
opcodes.dir file is out-of-date for one, so if we continue to use the
deferred plugin system that will need to be brought up to date and
synced manually whenever a plugin library that is packaged with Csound
is modified.  The second issue is whether the deferred plugin system
is worth keeping around as it has introduced maintenance issues and
bugs due to not being aware of it.

I don't know anything about how much of Csound's startup time is
involved with loading in the plugins.  I am wondering though if it is
significantly faster to use the deferred plugin system or not, how
much time is taken in parsing the opcodes.dir and going through the
extra overhead of library checking that is in the find_opcode
function.

For relevant code, it's all mostly in Engine/namedins.c, with the call
to build the library cache done in Top/csmodule.c.

Any thoughts?  Is this all worth using and maintaining and should we
all be careful to update opcodes.dir or shall we discontinue using
this?

Thanks,
steven

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net