QPlug Audio Plugin Framework

QPlug is in early development. The API changes without notice and nothing here is production ready yet.

Introduction

QPlug QPlug is a C++ framework for writing audio plugins. You write the DSP, the parameter logic and the user interface as three plain C++ classes; QPlug turns them into a native CLAP plugin and, through clap-wrapper, into VST3 and AudioUnit v2 as well, from the one implementation.

That last point is the whole design. A plugin is written once, against QPlug’s own types, and the formats are assembled from it. Plugin code contains no CLAP, VST3 or AudioUnit types, no per-format branch and no second implementation to keep in step, so the formats cannot drift apart. The only translation unit that knows a plugin format is QPlug’s own adapter.

QPlug is built on two other Cycfi libraries. Q provides the DSP and the audio-stream vocabulary the processor speaks. Elements provides the GUI, and its model interface is what links controls to parameters.

What a plugin looks like

Four functions are all QPlug asks for. It makes the three classes, hands each one what it needs, and answers the host on their behalf.

controller_ptr    make_controller();
processor_ptr     make_processor(controller& ctl);
presenter_ptr     make_presenter(controller& ctl);

plugin_info const& info();

The controller declares the plugin’s parameters, and nothing else about them has to be written. Here is the whole parameter list of the gain example, one automatable volume in decibels:

parameter_list gain_controller::parameters() const
{
   static parameter params[] =
   {
      parameter{ 1, "Volume", 0_dB }.range(silence.rep, max_volume.rep)
   };

   return { params };
}

From that, the host gets a parameter it can automate and save, the processor gets a value it can read on the audio thread without locking, and the presenter gets something a fader can bind to.

Around this, QPlug supplies what every plugin needs and nobody wants to write again: state and presets, the standard header along the top of the editor, zoom that survives a reopened session, and a test suite that runs the format validators against what you built.

The library is Open Source and released under the MIT License.

Where to go next

Setup and Building covers the prerequisites for macOS and Windows, how to build, and how to run the validation tests.
Architecture describes the three classes you write, how a parameter reaches both threads, and what the host adapter takes care of.
The reference describes each part in full: Parameters, declaring a parameter and what the host is told about it, Processor, the DSP and how the host’s events reach it at the sample they belong to, and MIDI, how a processor receives MIDI in every dialect a host sends.

Show Table of Contents

The Author

Joel de Guzman Joel got into electronics and programming in the 80s because almost everything in music, his first love, is becoming electronic and digital. Since then, he builds his own guitars, effect boxes and synths. He enjoys playing distortion-laden rock guitar, composes and produces his own music in his home studio.

Joel de Guzman is the principal architect and engineer at Cycfi Research. He is a software engineer specializing in advanced C++ and an advocate of Open Source. He has authored a number of highly successful Open Source projects such as Boost.Spirit, Boost.Phoenix and Boost.Fusion. These libraries are all part of the Boost Libraries, a well respected, peer-reviewed, Open Source, collaborative development effort.