| Istvan Varga wrote on 3/10/06 3:59 PM:
> 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.
Well I think the deferred loading is an interesting experiment -- but maybe
not necessary since "power users" can control which opcode libraries are
loaded with OPCODEDIR and --opcode-lib.
> 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 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).
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.
Just my two cents ...
> 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.
Separating out vbap is fine with me. Already did here with my local copy.
Anthony Kozar
anthonykozar AT sbcglobal DOT net
-------------------------------------------------------
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 |