Hi,
I'm planning on making opcodes to host VST plugins in Csound (for 
Windows XP), and have several questions regarding the new opcode plugin 
structure:

1- If I build a dll plugin, do I have to distribute a new compiled 
version of Csound, or just adding the dll to the opcode directory works?

2- Has a way of organizing "external" plugins been discussed? I ask this 
because something very annoying about puredata is not knowing what 
objects belong to what externals and not knowing what version of the 
external is included in a particular distribution. How about having a 
central repository of "unauthorized" plugins (those which haven't yet 
made it into canonical or which are platform specific) where both the 
sources and the compiled ddls can be found?

3- Any ideas on how documentation should be handled for these "external" 
plugins? One of the strengths of Csound is its comprehensive 
documentation. I think an effort should be made to ensure that continues.

Cheers,
Andrés

Andres Cabrera wrote:

> 2- Has a way of organizing "external" plugins been discussed? I ask 
> this because something very annoying about puredata is not knowing 
> what objects belong to what externals and not knowing what version of 
> the external is included in a particular distribution. How about 
> having a central repository of "unauthorized" plugins (those which 
> haven't yet made it into canonical or which are platform specific) 
> where both the sources and the compiled ddls can be found?

i think this is a good point (having experienced the same kind of 
confusion about pd externals you described above.)  it would be useful 
to have some kind of standardized way for organizing and packaging 
external plugin opcodes, complete with documentation, source, etc.  
actually, specifying guidelines like this for distributing user-defined 
opcodes would probably be a good idea, too. 

glyn

I think Michael's idea for a java program in the html help files that 
scan for html files inside the opcode directory is very good. That way 
documentation would stay together with the plugin, but still come out in 
the help files. This would be more a decision of the documenters (I hope 
they agree). Anyway, I think it would be good if external opcodes had 
their own directory, and inside it a folder called source with the 
sources. I think there's no need for anything else, apart from maybe a 
readme file which includes guidelines for building (like the additional 
lines for sconstruct).

Thinking about the documentation, it might be good to flag a plugin so 
it can be included in a category. Something I like about csound is that 
if I need a filter, I go to the documentation, search for filters, and I 
see all the filters available (something unthinkable in pd...). Maybe 
the plugin or the plugin documentation could be somehow flagged so that 
it is categorized accordingly...

Cheers,
Andrés

glyn wrote:

> i think this is a good point (having experienced the same kind of 
> confusion about pd externals you described above.)  it would be useful 
> to have some kind of standardized way for organizing and packaging 
> external plugin opcodes, complete with documentation, source, etc.  
> actually, specifying guidelines like this for distributing user-defined 
> opcodes would probably be a good idea, too.
> glyn
>