Host Facts

10/26/2014 1:28 AM
You can subscribe to this wiki article using an RSS feed reader.

The goal with this wiki is to collect all the things you never wanted to know about plug-in hosts, but still have to know.


Ableton Live

Versions Tested: 8.2
Platforms Tested: Windows x86, Mac PPC x86
Formats Tested: AU & VST

Latency Compensation: can be updated dynamically with ioChanged().

Keyboard Input: works fine with OS events (kEventRawKeyDown and WM_KEYDOWN).

Stepped parameters: Doesn't call getParameterProperties(). If a parameter is modified quickly in succession, Live will assume it is continuous and ramp the automation. Otherwise it will make a step.

updateDisplay() (or AU property change on kAudioUnitProperty_CurrentPreset or kAudioUnitProperty_PresentPreset) causes host to assume parameters have changed, stopping automation of the plug-in and lighting up the "back to arrangement" button.

Removing parameters in a plug-in update will result in Live trying to set parameters with indexes out of range when loading old projects.

getParameterDisplay() is called from audio thread.

stops calling process if for some time silence (and no midi events) was outputted and gui is closed. (bad if you have for example a midi sequencing plugin). Workaround send CC's all the time to stay active

Does not use setBypass(). When an effect is deactivated it is "suspended" and bypassed by Live itself, not by the plug-in.

Apple Logic

Versions Tested: 9.1, 10.0.7
Platforms Tested: Mac PPC x86 x64
Formats Tested: AU

Latency Compensation: can be updated dynamically. (ML 20120208: but how exactly?)

Cosmetic issue: plug-ins should be at least 385 pixels wide to look good.

Parameter order in "kAudioUnitProperty_ParameterList" seems to matter for automation data binding, despite the fact that parameters are referenced with arbitrary 32-bit IDs ("AudioUnitParameterID") in the Audio Unit standard. In other words if you change the order of parameters between versions, old projects will not load correctly. This is just as bad as with VST.

Automation data seems to be integer based and resolution is very poor (7-bitishy?). Exact resolution depends on type of "AudioUnitParameterUnit" and "minValue" -> "maxValue" range. (Maybe something like (maxValue-minValue)*10?). There is a parameter flag to enable higher resolution ("kAudioUnitParameterFlag_IsHighResolution"), but turning this flag on breaks backwards compatibility. Automation data created before turning this flag on will load, but scaled bizarrely (something around 77%). Buggy.

Avid ProTools

Versions Tested: 9.00
Platforms Tested: Windows x86
Formats Tested: RTAS

Time sync is totally broken in 9.00 with multi-core processing turned on. Sometimes it works, but most often not.

Cakewalk Sonar X1

Versions Tested: 184 (ML 20120208: say what?)
Platforms Tested: Windows x86 (ML 20120208: what about x64?)
Formats Tested: VST

Keyboard Input: Sonar has a "give all keystrokes to plugin" option at the top of the plugin-window, with it on, the host stops catching hotkeys but the plug-in still gets no keys. Saw this reported on their forum for other plugins having naming problems.

Cockos Reaper

Versions Tested: 3.72
Platforms Tested: Windows x86, Mac x86 (ML 20120208: what about x64?)
Formats Tested: VST (ML 20120208: AU?)

Keyboard Input (Windows only, Mac?): Most keys work, but digits 0-9 does not care about shift, and letters A-Z are always uppercase. No keyboard input is processed at all in 32-64 bridged mode.

ImageLine FL Studio

Versions Tested: 10.0.9
Platforms Tested: Windows x64 (ML 20120206: what about x32?)
Formats Tested: VST

Keyboard Input: Only [a-z0-9 \n] works. Keys like [,.-] triggers note on in the host and is not sent to the plugin. Shift state is not passed at all. (same as VSTHost) 

64->32 Bridge is buggy. Reproducible with GuitarRig and heavy parameter automation.

Window handling bad, you can't drag and drop something out of pluginwindow, FL will close plugin window.

Magix Samplitude Pro

Versions Tested:
Platforms Tested: Windows x86
Formats Tested: VST

Keyboard Input: Does not pass [space] or any key that is bound in the host (like , and ?), which makes it lose focus and you need to close and open the plugin again.

Plasq Rax

Versions Tested: 2.0.2
Platforms Tested: Mac x86
Formats Tested: AU

Doesn't seem to stop audio processing calls before calling exit handlers / global destructors (possibly only when GUI is open. To research: when exactly are these called nowadays, when the plug-in is being unloaded?).

Steinberg Cubase

Versions Tested: 5.5
Platforms Tested: Windows x86 x64 (ML 20120206: what about Mac?)
Formats Tested: VST

Crashes if you call ioChanged() from processReplacing(). getCurrenProcessLevel() can only be called from processReplacing() on the other hand, so if you want to change latency for off-line rendering you are pretty much effed.

Steinberg VST Bridge

Versions Tested: 5.5
Platforms Tested: Windows x86
Formats Tested: VST

Runs GUI in different thread than from which it loads and initialize the VST (bad for "fxIdle" timer, since you can't create it in the right thread from the start). Update: even worse, each GUI gets its own thread (a mine-field for thread safety). Also, closing of editor and destruction of vst instance can happen simultaneously.

Steinberg WaveLab

Versions Tested: 6 7
Platforms Tested: Windows x86
Formats Tested: VST

Calls fxIdle from non-GUI thread (I think... Andy?). Apparently calls effEditClose and / or effClose from a different thread than the one opening (again according to Andy.)


Threading Issues

Todo: explain how an ideal host behaves with multiple threads (all the way down to which methods we expect to get called from which threads)

Here is a little check list of things to look for when analyzing the multi-threading behavior of a host:

  1. Which thread(s) initializes / constructs the plug-in and is it the same for all instances? (VSTPluginMain and effOpen)
  2. Which thread(s) opens the GUI (effEditOpen) and again, is it the same for all isntances?
  3. Which thread(s) closes the GUI, is it the same as the thread opening it? (effEditClose)
  4. Which thread(s) closes / destructs the plug-in, is it the same as the thread constructing it? (effClose)
  5. Which thread(s) calls fxIdle and does it stay the same? (effIdle)
  6. Which thread(s) calls idle and does it stay the same? (effEditIdle)
  7. Which thread(s) calls process, can there be multiple threads processing concurrently (i.e. multi-core support)? (this should be ok though)
Home: Host Facts What's new: Recently changed articles