###### Abstract  
This article presents a new framework for unit generator development for Csound, supporting a full object-oriented programming approach. It introduces the concept of unit generators and opcodes, and its centrality with regards to music programming languages in general, and Csound in specific. The layout of an opcode from the perspective of the Csound C-language API is presented, with some outline code examples. This is followed by a discussion which places the unit generator within the object-oriented paradigm and the motivation for a full C++ programming support, which is provided by the Csound Plugin Opcode Framework (CPOF). The design of CPOF is then explored in detail, supported by several opcode examples. The article concludes by discussing two key applications of object-orientation and their respective instances in the Csound code base. osurmc  
the term _opcode_ more generally to denote a UG of any kind. Internally, all operations are implemented by opcodes/functions (including all primitive arithmetic and control-of-flow), which places them as a central pillar of the system. Some of these of course are going to be minimal and light-weight, and others can be of significant complexity. Csound has a collection of internal or built-in opcodes that are compiled into the system, but also provides a mechanism for adding new opcodes [7]. This mechanism is made up by two separate components, namely  
1. An interface for registering new opcodes, provided by Csound API. 2. Dynamic library loading is provided by the audio engine at startup. As part of this, a given directory is searched for suitable library files containing new opcodes. Opcodes are usually written in C, although other languages producing a compatible binary format can be employed. Each opcode will be defined by a dataspace and up to three processing functions that are called by the engine at different times depending on the type of signals that are to be processed. An opcode is invoked by Csound code in units called _instruments_ or _user-defined opcodes_ (UDOs). The engine will instantiate it by allocating space for its data, and call its processing functions according to one or more of two action times (_passes_):  
1. **initialisation time**: code is executed once, after instantiation. It can also be invoked again if a re-initialisation pass is requested. 2. **performance time**: code is executed repeatedly each control cycle to consume and/or produce a signal. There are two separate types of functions that can be defined for performance: 1. **control**: this function is invoked to deal with scalar inputs or outputs (e.g., processing a single sample at a time). 2. **audio**: code is expected to deal with audio signals, which are passed as vectors to it. The three processing functions defined by an opcode are each connected to one of the processing cases listed above. They are also linked to the different types of variables supported by the Csound language, which the opcodes will be designed to operate on:  
* i-type: these variables are floating-point scalars that can only change at initialisation or re-initialisation time. * k-type: also floating-point scalars, these will only change at performance time, although they can also be initialised at i-time. * a-type: this is a floating-point vector, which is modified at performance time. The length of this vector is defined by a ksmps variable that can assume local (instrument) values or can be set globally for the whole engine. Vectors can also be initialised at i-time. Audio-rate functions are designed to operate on these variables. * S-type: character strings, which can be modified at i-time and perf-time, although it is more common to do so only at i-time. * f-type: frequency-domain signals (fsigs), these contain self-describing spectral data (of different formats) that are processed at performance-time by control-rate functions. * arrays: composite-type variables of each of the above types. A very important case is k and i arrays, for which there are various important applications.