plugin_host_type.h
Which host loaded this plugin, and as which format.
#include <sonore/plugin_host_type.h>- 1type
- Guides: Getting started, Parameters and state, Presets
On this page
Design notes
Why this exists after all
The feature map once called this deliberately absent: a plugin branching on a host's NAME grows a code path per DAW that nobody can test, and outlives the bug it was written for by years. That is still the right first answer, and it is why every host difference this SDK knows about is asked of the host as a CAPABILITY in the wrappers -- does it offer a context menu, does it answer a resize request -- rather than by name.
It stopped being the whole answer for two reasons. Code ported from the reference asks isReaper() and isLogic() and has nowhere to go without this class. And some host differences are not capabilities at all: a host that reports a block size and then exceeds it, a host that calls process before activate. There is no question to ask; there is only knowing who you are talking to. HostInfo -- the name a CLAP host gives in clap_host, a VST3 host through IHostApplication, an AU host through kAudioUnitProperty_AUHostIdentifier, the standalone for itself -- was the first half of that, and a name a host chooses for itself is not reliable: LV2 says nothing, an AU host need not, and two hosts may call themselves "Plugin Host".
What it looks at, in order
1. The macOS bundle identifier of the process, which Apple guarantees is unique and stable across a product's renames: com.apple.logic10 is Logic whatever the app is called this year. 2. The EXECUTABLE -- its file name and its path -- which is what the reference uses everywhere and the only thing available for an LV2 instance, or an AU one whose host does not name itself. A host that runs plugins in a helper process is seen as that process: Bitwig's BitwigPluginHost64 still says "bitwig", REAPER's reaper_host64 still says "reaper". 3. The name the host reported, when the executable said nothing useful. Except for this SDK's own standalone, whose report is read before anything else: its executable is named after the plugin, and a plugin called "Sonar Delay" is not running in SONAR.
On Windows the version comes from the executable's version resource, read through version.dll loaded at run time so nobody has to add version.lib to a link line for a header. On macOS it is CFBundleShortVersionString. Linux has no standard place, so it is whatever the host reported.
What it sees only when told
Logic on Apple silicon runs Audio Units in AUHostingService, a process that is not Logic and is not called Logic. The AU wrapper reads the name the host sets in kAudioUnitProperty_AUHostIdentifier and hands it over as HostInfo, so a PluginHostType made from that classifies by the reported name (rule 3). A host that never sets the property leaves the process unknown rather than guessed. The version there is still the process's own bundle version where it has one, as everywhere on macOS.
Types 1
The host this plugin is running in, as far as can be told.
Cheap to construct but not free -- it reads the executable's path and, on Windows, its version resource -- so a plugin makes one when it starts, or in setHostInfo(), and keeps it. Main thread: nothing here belongs in process().