## 2 The Framework
### Registering Opcodes with Csound
To use it, the plugin needs to declare and implement a deinit() method and then call the plugin_deinit() method passing itself (through a this pointer) in its own init() function:

csound->plugin_deinit(this);

Because of the presence of the opcode object as an argument, the compiler resolves the template instantiation without requiring an explicit template parameter. ## 4 Toolkit Classes

Plugins developed with CPOF can avail of a number of helper classes that compose its _toolkit_. These include the aforementioned Params class, as well as classes for resource allocation, input/output access/manipulation, threads, and support for constructing objects allocated in Csound's heap. ### Parameters

As we have already discussed in Section 2.2, parameters passed to a Csound opcode instance are encapsulated by the Params class so that they can be conveniently accessed. The class has the following public methods:

* operator[](): array-style access to numeric (scalar) parameter values. * begin(), cbegin(): begin iterators for the parameter list. Figure 2: The Csound engine class, derived from the opaque C structure CSOUND. * end(),cond():end iterators. * iterator andconst_iterator:iterator types for this class. * operator()()():function-style access to numeric (vector) parameter pointers. * data():same as the function operator, access to the parameter address. * str_data():access to parameter as a STRINGDAT reference (see Section 4.5). * fsig_data():access to parameter as a Fsig reference (fsig data class, see Section 5). * vector_data():access to parameter as a Vector<T> reference (Csound 1-D numeric array data, see Section 4.6). * myfltvec_data():access to parameter as a myfltvec reference (Csound 1-D numeric array, see Section 4.6). As we can see, this is is a thin wrapper over the argument pointers, which translates between the original MYFLT\(*\) and the various argument types, and allows for iteration over the parameter lists. ### Audio Signals

As outlined in Section 1.1.1, audio signal variables are vectors of nsmps samples and we can access them through raw MYFLT pointers from input and output parameters. While this works well in a C-language environment, it is possible to provide a better object-oriented support to the manipulation of vectors through encapsulation. The AudioSig class wraps audio signal vectors conveniently, providing iterators and subscript access:

* operator[]():array-style access to individual samples. * begin(),cbegin():begin iterators for the audio vector. * end(),cond():end iterators. * iterator and const_iterator:iterator types for this class. * operator()()():function-style access to numeric (vector) parameter pointers. Objects are constructed by passing the current plugin pointer (this) and the raw parameter pointer. The final parameter is flag for an optional resetting of the audio signal vector:

AudioSig(OPDS *p, MYFLT *s, bool res = false);

With this, we can re-write the simple audio example opcode to use this class and its iterators in a typical C++ idiom, as demonstrated in Listing 5. ```
structSimplea:csnd::Plugin<1,1>{ intaperf(){ csnd::AudioSigin(this,inargs(0)); csnd::AudioSigout(this,outargs(0)); std::copy(in.begin(),in.end(),out.begin()); returnOK; } }
```
### Memory Allocation

Csound provides its own managed heap for dynamic memory allocation. The engine provides mechanisms to allocate space as required. This ensures that there are no leaks and that there is an efficient use of resources. When an opcode requires a certain amount of space that is not known at compile time, it can avail of this mechanism to get access to it. It is not advisable for developers to employ any other memory allocation methods. In C, this means that standard library functions malloc etc should be avoided. In C++, we should avoid to use the new operator (new) and containers that employ it (for instance, std::vector).