To me it does not matter whether opcodes that are in the Csound official 
distribution are in one library or many. The reason I created the plugin 
opcode idea in the first place was not so much modularity (though that is a 
reason) but, even more, to permit other, non-Csound developers to create 
opcodes that are NOT in the official distribution without having to rebuild 
the whole shebang. This would speed up computer music research and also take 
some of the load off the Csound developers.

All the parts are in place to permit this, yet it still has not quite 
happened. I still don't see Perry Cook maintaining the STK opcodes or Kelly 
Fitz maintaining a (working) Loris plugin.

What we need now is a "software development kit" designed for maintaining 
plugin opcodes, and to get the message out: port your stuff to Csound 
plugins.

Regards,
Mike

----- Original Message ----- 
From: "Anthony Kozar" 
To: "New Csound Developer list" 
Sent: Friday, March 10, 2006 10:26 PM
Subject: Re: [Cs-dev] plugin reorganization


> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 





-------------------------------------------------------
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