Thanks for raising this issue, but as far as I know there isn't (yet) a
standard.

In the version of Csound 5 that I am working on, Csound scans the directory
pointed to by the environment variable OPCODEDIR and probes each file for
the size and init functions; if these are found the opcode's OENTRY records
are added to the opcodlst array. This is in addition to the already existing
command-line option for loadable opcodes, which is still in operation.

John Fitch and I seem to have somewhat different understandings about
plugins. I contributed the plugin idea some years ago as a means of making
it easier for developers to extend Csound. I had no intention of moving
existing opcodes to plugins, except where contributed plugins have licenses
incompatible with the LGPL, in which case the dynamic loading resolves the
license issue. (I don't know WHICH opcodes need to be loadable for this
reason!). John went ahead and tried to make all the opcodes into plugins,
but he has never really said why.

As it happens, it's not so easy to make all the opcodes into plugins, so
many are and many aren't. I understand perfectly well that this makes your
job more difficult.

I don't think this needs to make much difference to you. You can identify
opcodes to document as follows: everything in entry1.c and entry2.c as
before, plus all code in the Opcodes directory that has a target in the
build system (ends up as a dll or so). The same data that used to be
entry1.c and entry2.c is now in each plugin's .c file in the Opcodes
directory, and you can grep for OENTRY to locate the OENTRY records.

Of course, there are always other possibilities. Please do not interpret my
ideas as criticisms of your excellent work, which I use constantly.

Documentation could be generated using doxygen from comments in the code.
This would serve to document each exposed structure, function, and opcode.
The Csound command could even be documented by adding code comments to the
main() function. You could move your documentation from its current sources
into the actual source code. The rebuilding of the documentation into html,
pdf, etc. would then be a part of the regular build process. Then the
documentation could stay more or less up to date with the current state of
the code.

It would also be possible to insert the documentation directly into the
source code, not as comments, but as static strings; a const char *docstring
member of the OENTRY structure. Then Csound itself could scan the opcodlst
table to build up an internal documentation system, which could be printed
out online using a "--help keyword" option, or displayed in some sort of
online help browser in GUI versions of Csound.





============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "Kevin Conder" 
To: "Csound Developers Discussion List" 
Sent: Monday, February 16, 2004 12:09 PM
Subject: [CSOUND-DEV:4065] Re: soundouts


> John ffitch wrote:
>
> > Can anyone see a reason for keeping this opcode
> > in the system?  It appears to be a noop and is
> > not in the Alternative Manual.
>
> I'd like to point out that I use the files entry1.c and entry2.c to
> determine which opcodes to include. The soundouts entry was commented
> out in the entry1.c file so that's why it isn't in the manual.
>
> BTW, I hope the new every-opcode-as-a-plugin scheme is as easy to
> follow as the entry*.c files. Are they all going to be in the same
> sub-directory?  Is there going to be a standard, consistent layout for
> opcodes?
>
>
> =====
> -- 
> kwconder at yahoo dot com
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online.
> http://taxes.yahoo.com/filing.html
>