I have been experimenting with deferred loading of opcode plugins only when
the orchestra actually references opcodes in a particular library. With this
it may make sense to have separate smaller libraries, rather than a single
large one. I have not yet decided, though, if this is really a good idea
compared to just merging most opcodes (those that have no external
dependencies) into a single all-in-one plugin that is loaded unconditionally.
So, I have no objection to reverting this change (perhaps the new barmodel
opcode could then be just moved into stdopcod, by the way); should I revert
it ?

I still think that the vbap opcodes should be moved out of the API library,
though, or into stdopcod if the deferred loading hacks are removed.

On Friday 10 March 2006 20:51, Anthony Kozar wrote:

> I noticed just now that the opcode plugins have undergone another
> reorganization including moving the vbap opcodes out of the main Csound5
> library and several opcodes out of the stdopcod library.  I am curious what
> the purpose of these changes is?
> 
> Also, in the future, could everyone please make the effort to announce major
> changes to the codebase (changed targets, moved files, new files, deleted
> files, changes to the API) to the dev list and include a note in the
> ChangeLog.  Otherwise I have no idea that I need to adjust my build system
> on MacOS 9.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net