I am very glad to see you taking on this task, and I sincerely hope that you
succeed. In response to your questions:

1- The user only needs to copy your dll to their opcode directory. There is
no need to rebuild Csound or even to update any configuration files or
anything like that. Each time Csound 5 (or CsoundVST) starts up, it scans
the opcode directory and probes each dll (on Windows) or so (on Linux) or
dynlib (on OS X) file to identify opcodes, then automatically loads all
identified opcodes.

2- If you create a reliable VST hosting opcode, you can either (a) ask John
ffitch to become a Csound developer and add your files to Csound 5 CVS, or
(b) email me your project and I will add the files to CVS and also to the
Csound 5 build system. There has been no discussion of organizing plugin
opcodes because there are not as yet very many plugin opcode developers. If
there were a lot of new plugin opcodes, some of them available only on some
platforms or some of them not well tested, then I think that the csounds.com
Web site could asked to host a plugin repository.

3-Documentation of plugins -- that's a very good question. For now,
providing an HTML page in the format of the Conder manual would be a good
start: myplugin.htm for myplugin.dll. Probably some Javascript could be put
into the HTML form of the manual to scan the opcode directory for these
pages and dynamically insert them into the manual.


----- Original Message ----- 
From: "Andres Cabrera" 
To: "Csound Developers Discussion List" 
Sent: Tuesday, June 01, 2004 6:44 PM
Subject: [CSOUND-DEV:4790] opcode plugins question


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

> 1- The user only needs to copy your dll to their opcode directory. There is
> no need to rebuild Csound or even to update any configuration files or
> anything like that. Each time Csound 5 (or CsoundVST) starts up, it scans
> the opcode directory and probes each dll (on Windows) or so (on Linux) or
> dynlib (on OS X) file to identify opcodes, then automatically loads all
> identified opcodes.

Yes, I tried this, and it's working. The build system with sconstruct 
work very well.

> 2- If you create a reliable VST hosting opcode, you can either (a) ask John
> ffitch to become a Csound developer and add your files to Csound 5 CVS, or
> (b) email me your project and I will add the files to CVS and also to the
> Csound 5 build system. There has been no discussion of organizing plugin
> opcodes because there are not as yet very many plugin opcode developers. If
> there were a lot of new plugin opcodes, some of them available only on some
> platforms or some of them not well tested, then I think that the csounds.com
> Web site could asked to host a plugin repository.

Yes, or maybe a sourceforge project could be opened, but it's true that 
it is still early, so it can be decided later.

> 3-Documentation of plugins -- that's a very good question. For now,
> providing an HTML page in the format of the Conder manual would be a good
> start: myplugin.htm for myplugin.dll. Probably some Javascript could be put
> into the HTML form of the manual to scan the opcode directory for these
> pages and dynamically insert them into the manual.
Good idea, can something like this be done for the winhelp? I find the 
winhelp more convenient, when using WinXound.