Quantcast
Channel: KVR Audio
Viewing all articles
Browse latest Browse all 7115

DSP and Plugin Development • Convenience classes for CLAP plugins and "AGain"-like examples

$
0
0
In the last two weeks, I have finally gotten around to learn the CLAP-API - or at least the most important parts of it. To get started, I was trying to find example code similar to the well known "AGain" example from the VST-SDK. But the examples that I could find were all either too low level (written against the core C-API, featuring a lot of boilerplate code) or missing essential features (like handling state recall) or too complicated (involving GUI stuff with various frameworks) or written in the (for me) wrong language (Rust) or a combination of the above. A simple "AGain"-like example based on this convenience wrapper class:

https://github.com/free-audio/clap-help ... /plugin.hh

that does all the usual stuff like handling parameters and state recall but is not burdened with the additional layer of complexity of handling a GUI framework did not yet seem to exist (Or does it? If so - where?). I also wanted to understand how the C++ wrapper class around the core C-API actually works - how is it all glued together? To figure this out, I found the wrapper class a bit big. It implements loads of features that I wasn't interested in (at least for the time being - as a beginner) and buried a lot of the functionality in the error handling. So I sat down and stripped away all the stuff that I do not (yet) need and simplified the error handling to use simple assert-statements. Then I created subclasses of my simplified wrapper class and in these subclasses I added stuff that I do need but was not yet present in the wrapper - such as parameter and state handling.

The result of all of that is a C++ class from which actual plugins can conveniently be derived and whose code can look quite similar to Steinberg's "AGain" example as demonstrated in this pair of .h/.cpp files:

https://github.com/RobinSchmidt/RobsCla ... oPlugins.h
https://github.com/RobinSchmidt/RobsCla ... lugins.cpp

They actually contain two plugins - a gain plugin with "Gain" and "Pan" parameters and a waveshaper plugin with "Shape", "Drive", "DC" and "Gain" parameters. To build the actual plugin library, one also needs the file:

https://github.com/RobinSchmidt/RobsCla ... yPoint.cpp

for the entry point of the dll/so/... There is a Visual Studio solution with a project that builds this .clap plugin library:

https://github.com/RobinSchmidt/RobsCla ... pStuff.sln

So far, I have compiled this only on Windows with Visual Studio. At some point, I want to make this code portable to Linux and MacOS, too - but it's not there yet. The resulting .dll (actually .clap - but it's really just a renamed .dll) passes all tests in the clap-validator.exe application and seems to work as expected in Bitwig. This project demonstrates also how to put more than one plugin into a single library and the "Shape" parameter in the waveshaper demonstrates how one could handle choice/enum parameters. All of the state-recall handling and much of the parameter handling has been factored out into the baseclass which in this case is ClapPluginStereo32Bit. It is actually itself a subclass of the more basic and more general baseclass ClapPluginWithParams. These classes are implemented here:

https://github.com/RobinSchmidt/RobsCla ... nClasses.h

I do not yet recommend to derive directly from ClapPluginWithParams, though. Some more work needs to be done on it before (see documentation). But if you have the (rather common) case of a stereo I/O plugin that works with 32 bit float data, it should be very convenient to derive from the class ClapPluginStereo32Bit and override a couple of virtual member functions. You should override at least two: processBlockStereo() for the actual audio processing and parameterChanged() to handle parameter changes. You may optionally also override some more functions to get customized text formatting for your parameters (see the examples).

Disclaimer:
I am not saying that this code any good or production-ready or publication-ready or anything like that. It's just something that I came up with and that I want to use personally as a basis for some GUI-less plugins. It's mostly meant to be educational to show how things *could* be done - not necessarily how they *should* be done in any sort of "best practices" sense. There is definitely some more work that needs to be done. So, use it at your own risk.

Any comments, feedback, bug-reports, suggestions for improvements, etc. are welcome

Statistics: Posted by Music Engineer — Sat Apr 13, 2024 11:09 pm — Replies 0 — Views 19



Viewing all articles
Browse latest Browse all 7115

Trending Articles