The Vocal Processor Experience

The Vocal Processor was a research project developed in our group for the Yamaha Company, Japan. The Vocal Processor is a VST plugin for singing voice processing that implements spectral domain techniques. It is designed to run on real-time and, because of its complex algorithms, demands many computer resources.

The initial implementation was done in C++ but the code was highly unstructured and hardly maintainable. For that reason it was decided to port the code to the CLAM framework (see chapter 3). Once the VST plugin was running in its CLAM version, it was discovered that this implementation was almost one hundred percent slower. The first impression was that the Object-Oriented techniques and overall design of the framework were causing this and that it would not be possible to compete with the fine-tuned but highly unstructured original code. The process that followed, and demonstrated that other reasons were behind that bad performance, illustrates the overall message of this section.

None of the efficiency problems found in this application were related to any of the previously mentioned prejudices against object-orientation: encapsulation, modularity, or inheritance. As a matter of fact, having a clear and clean design and code enabled a fast refactoring that ended up in having a fully object-oriented CLAM version of the plugin that was even about thirty percent faster than the original one.

Using specialized profiling tools, the efficiency hotspots were found. These are the main actions that had to be taken in order to improve the first CLAM version:

1. Algorithm improvement: some algorithms were not well implemented and contained efficiency bugs. These efficiency bugs were usually related to unnecessary memory allocations and independent loops.
2. VST interface improvement: the incoming data from the VST host was not being correctly handled and this meant having unnecessary memory allocations of large memory blocks.
3. Inefficient low level routines: the Microsoft Windows implementation of some low level routines such as float to integer conversion or absolute number were causing an overall slow down of the process. Surprisingly, this was one of the most significant factors. Such functions were being called millions of times during the whole process and the overall effect was really worrying. We finally ended up implementing these routines in assembler code.
4. Compiler settings. The VST plugin was being compiled for Windows with the Microsoft Visual Studio environment. This compiler has some obscure settings that had to be tuned in order to find the best combination.
5. Incorrect thread handling.

From this use case it is clear that the object-oriented paradigm did not introduce any efficiency trap. Furthermore, it facilitated the improvement of the original code because of its modularity and clear structure.