iPlug2 allows building of plug-ins where the DSP and Editor/GUI parts are separated. This approach is necessary for building Web Audio Modules, but it's also an option for VST3 (possibly other formats in the future). By "separated", we mean the DSP might be running in an isolated process or sandbox, and the Editor/GUI in another place and you cannot "get a pointer" to one from another. In the DSP part, you can't directly access the memory address of a GUI control, and in the GUI, you can't directly get access to the memory address of data that is needed by the audio processing code. Instead of communicating directly you send messages in-between the two parts, and iPlug2 has a system for doing this safely. In order to keep the code for a plug-in concise iPlug2 lets you make distributed plug-ins by compiling the same C++ code twice. In one compilation IPLUG_EDITOR is defined and in the second IPLUG_DSP is defined. Code for e.g. setting up parameters is shared by both parts so that GUI and DSP can access the parameters, using the same methods. Behind the scenes, iPlug2 takes care of synchronising the parameters across the two places.

If you are not interested in building a WAM and you don't like seeing #ifdef IPLUG_EDITOR etc in your code, you can delete the guards to make your code clearer.

For distributed VST3 plug-ins the VST3 Controller is compiled as a static library with IPLUG_EDITOR set. By default compilation will fail because when the library is linked with the VST3 Processor there will be conflicting symbols. To solve this you can replace all occurrences of the class name in your main .h and .cpp file with a preprocessor macro. To do this for IPlugEffect, we could change all occurrences of e.g. IPlugEffect to PLUG_CLASS_NAME, which will be modified when building the VST3 Controller library.

Read more about "distributed" plug-ins in our2018 WAC paper.