*Warning*

You might want to read the file Submitting_opcodes.md

==John ff

Protocol for submitting new opcodes
===================================

The developers are happy to accept code for new opcodes (and other
parts) but in order to make the process simple and clear we have drawn
up this protocol in the hope that it will avoid embarrassing delays and
discussions.


Licence
-------

In general Csound is licenced with LGPL so submissions need to have that
licence or a compatible one.  Note that GPL is a problem.

Examples of suitable copyright and licence text can be found at the
start of most opcode files.

Names
-----

New opcodes should not have names that start with the letters i, k, f
or a.  This is to avoid name clashes with existing orchestras; and yes
it has happened in the past.

Coding
------

Please follow the general style; it is important not to have any
static variables which are not constant, while static fuctions are
encouraged.  Any use of external libraries which introduces new
dependencies is a potential problem and may be best discussed with the
core team.

Note that Csound is compiled with -Werror so code must be clean; no
unused variables, no mixing of signed and unsigned integers etc.

In the OENTRY list take care to include the semantic information in
the third field if the opcode reads or writes ftables, ZAK or
channels, or prints things other than messages.  If in doubt ask.
Also note that the fourth field should have values 1,2, or 3.  Not 4
or 5.

Formatting/Indentation
----------------------

Ideally C code should not have any tab characters in it, and be
limitted to 85 characters wide.  Format should be similar to existing
code.  Also wrap any error strings with a call to Str to assist with
language translations.

Sample-accurate
---------------

If an opcode returns a audio-rate value or uses audio-rate input it
must include support for sample-accurate mode.  Again looking at
existing opcodes shows a template for this.

The template for arate perf-pass opcodes is:

     int perf_myopcode(CSOUND *csound, MYOPCODE *p)
     {
         uint32_t offset = p->h.insdshead->ksmps_offset; // delayed onset
         uint32_t early  = p->h.insdshead->ksmps_no_end; // early end of 
event
         uint32_t nsmps = CS_KSMPS;
         ...
         // Clear parts of the output outside event
         if (UNLIKELY(offset)) memset(p->res, '\0', offset*sizeof(MYFLT));
         if (UNLIKELY(early))  {
           nsmps -= early;
           memset(&p->res[nsmps], '\0', early*sizeof(MYFLT));
         }
         for (n=offset; nres[n] = ....
         }
         return OK;
     }


Core or Plugin?
---------------

New opcodes can be either in the core library, or available as
plugins.  Which is used depends on a number of factors.  If an opcode
has external dependencies it can ONLY be added to the Csound standard
codebase as a plugin. For platforms where plugins are not available,
special packages can be prepared to include an opcode and its
dependencies within the core library.  if the opcode is only useful on
one platform (like the Linux joystick opcode) then a plugin is to be
preferred.  For others it is a balance between code growth and
utility.


Documentation
-------------

All new opcodes or gens need a manual page, if only a minimal
one. Even better if it includes an example .csd file.  There is a
template in the manual tree opcodes/template.xml, and example files in
the examples directory.


Submission
----------

Probably easiest as a pull request on github, but direct mail to the
developers' mailing list or direct contact with a core developer are OK.

==JPff 2017 Dec 14
   updated 2018 Oct 03



On Wed, 18 Nov 2020, Victor Lazzarini wrote:

> You can either send the code to one of us or do a PR in github. PRs are
> handy.
> 
> and yes, if this is different from what we already have, it's very welcome. 
> 
> Prof. Victor Lazzarini Maynooth University
> Ireland
>
>       On Nov 18, 2020, at 12:28 AM, Roger Kelly 
>       wrote:
> 
> I am about to port an open source DX7 envelope algorithm from
> Javascript to Python for use in an orchestra emulator.
> If it works well, would there be interest in a Csound "C" opcode for
> this?  The envelope is very particular to the DX7 and none of the
> current envelopes would get it quite right.
> 
> Is there a code review process or how does that work to submit a new
> opcode?
> 
> 
> Thanks.
> Roger
<

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

My gut feeling is that this might be better suited as an opcode
library or implemented in user code rather than as a C opcode in the
core. I'm curious, any particular reason why not to implement this as
an opcode library?

On Tue, Nov 17, 2020 at 7:28 PM Roger Kelly  wrote:
>
> I am about to port an open source DX7 envelope algorithm from Javascript to Python for use in an orchestra emulator.
>
> If it works well, would there be interest in a Csound "C" opcode for this?  The envelope is very particular to the DX7 and none of the current envelopes would get it quite right.
>
> Is there a code review process or how does that work to submit a new opcode?
>
>
> Thanks.
> Roger
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here