The Applications Programming Interface
In order for the client-server scheme to work, both the client and DLL/plug-in must agree on the naming of the functions. This includes the creation function and all of the functions that the client will be able to call on the plug-in object. The plug-in might have other functions that the client doesn’t know about, but they must agree on a basic set of them. Additionally, rules must be set up to define the sequence of function calls; the plug-in’s author (that’s you) will need to understand how the client intends to use the object.
The client must make sure that once it establishes these rules it adheres to them in future versions to avoid breaking the plug-in. On the other hand, the plug-in must also promise to implement the basic required functions to make the plug-in work. So, you can see that there is an implied contract between the client and DLL server. This contract is the applications
programming interface or API. It is a definition of the functions an object must implement to be considered a proper plug-in as well as any additional functions that may be called or overridden. It defines the function prototypes and describes how the functions will be called and used. The API is written by the client manufacturer and is made available to programmers who want to create plug-ins for that target client. Some examples are Direct-X ® , VST ® , AU ® , and AAX ® . Each of these manufacturers publishes an API that describes the contract with the plug-in developers. However, the basic operation and core functionality are generally the same.
C++ is especially useful here. Since the plug-in is an instance of a C++ object, the client manufacturer can specify that the plug-in is a derived class of a special base class that it defines. The base class is made to be abstract, containing virtual functions that the derived class overrides. These virtual functions provide the common functionality of the plug-in. There are two options here:
1. The manufacturer defines the base class as abstract and then provides default implementations of the virtual functions. Typically, the default implementations do nothing but return a success code. The plug-in authors then override whichever methods they need to. For example, the plug-in might not care about responding to Musical Instrument Digital Interface (MIDI) messages, so the default implementation of the MIDI function will suffice.
2. The manufacturer defines the base class as a pure abstract base class by making one or more of the virtual functions pure virtual functions. A pure abstract base class cannot be instantiated; only derived classes that implement all the pure virtual functions can. This forms a binding contract between the plug-in developer and the client manufacturer since the derived class won’t work properly unless it implements the pure abstract functions that the client specifies.
The RackAFX software uses the first method, supplying default implementations for all virtual functions. As the plug-in author, you only override the functions you need to. But what are the typical required functions and where do they come from?
Excerpt from Designing Audio Effect Plug-Ins C++ by Will Pirkle.
About the Author
Will Pirkle is an Assistant Professor of Music Engineering Technology at the University of Miami Frost School of Music, where he teaches C++ audio programming, signal processing, audio synthesis, recording studio workshops, and mobile app programming. In addition to his nine years of teaching, Mr. Pirkle has twenty years of experience in the audio industry, during which he worked and consulted for companies including Korg Research and Development, SiriusXM Radio, Diamond Multimedia, Gibson Musical Instruments, and National Semiconductor Corporation. An avid guitarist and studio owner, Mr. Pirkle continues to seek projects that combine all his skills.