Note to plug-in developers: implement support for these APIs to encourage host developers to add support for it.

Note to host developers: implement these APIs to encourage plug-ins to support them.

REAPER supports VST plug-ins (up to version 2.4 as well as version 3, though this document only applies to version 2.x). VST is a standard defined by Steinberg Media Technologies GMBH. To get the VST SDK (which you will need to implement VST plug-ins), you will need to download it from Steinberg, as we cannot distribute it.

It is worthwhile noting that while VST is a standard, it is neither an open standard (because you cannot easily distribute the SDK or things derived from it), nor is it a well defined standard.

This document will describe some REAPER-specific implementation notes for VST, as well as list some REAPER-specific extensions to the VST SDK/API that plug-in developers are encouraged to use to achieve great integration with REAPER. Additionally, we encourage other VST host developers to add support for these extensions, as we believe they are useful.

REAPER currently implements a subset of the VST 2.4 standard as well as additional extensions-- this section discusses the former.

Audio/sample processing: REAPER will use processDoubleReplacing if effFlagsCanDoubleReplacing is set in the flags.
REAPER will use processReplacing if effFlagsCanReplacing is set and processReplacing != process (if it equals it assumes that it is a faulty implementation of processReplacing). Additionally there is an option in the preferences to not use processReplacing for buggy plug-ins. Note that for plug-ins that have Cockos extensions (see below), the option (to not use processReplacing) is ignored, allowing known-good plug-ins to always run at full speed.

Threading/concurrency: Since audio processing can run in other threads from the UI, it's important to note what can run at the same time. REAPER is highly optimized to prevent UI and other actions from interrupting audio, so assume everything can (and WILL) run at the same time as your process/processReplacing, except:

effOpen/effClose

effSetChunk -- while effGetChunk can run at the same time as audio (user saves project, or for automatic undo state tracking), effSetChunk is guaranteed to not run while audio is processing.

So nearly everything else should be threadsafe. For many things this doesn't mean having to do much, but there are plenty of plug-ins that barf when audio is running and you open the window (using effEditOpen). There is an option to bypass audio while opening the config window, but it sucks and shouldn't be required.

Dynamic parameters: REAPER can deal with the number of parameters for a plug-in changing on the fly. Use the extended host audioMasterAutomate callback described below to notify the host of parameter count changes (i.e. parameter X deleted, or new parameter Y), to preserve automation of higher indexed parameters when adding/removing lower parameters.

Multiple inputs/outputs: REAPER allows the user to dynamically connect input/output pins of VSTs wherever they want, so enable as much I/O as you need. REAPER also allows input/output counts to change, HOWEVER it is recommended that any changes you make be done from within processReplacing() or process(), and use the old value of numInputs/numOutputs until the next call. Additionally the initial value of numInputs/numOutputs should be set to the most common settings.

Longer labels: effGetParamName/effGetParamLabel/effGetParamDisplay all support up to 256 character strings (255+null).

REAPER on OS X is built using Cocoa and supports an extension which allows VSTs to create their UIs as Cocoa. Using Cocoa for UI of VST plug-ins within REAPER will result in a much cleaner integration, and has numerous advantages, including 64-bit (x86_64) support. We strongly encourage plug-in developers and other host developers to add support for Cocoa UIs via this API.

Note: on x86_64, REAPER assumes that all configuration windows are Cocoa, as Carbon is not supported.

When loading a VST plug-in on OS X, REAPER asks the plug-in if it would like to use Cocoa for its UI. This request is in the form of an effCanDo with the string "hasCockosViewAsConfig", looking for the response of 0xbeef0000 - 0xbeefffff (the low 16 bits are ignored). If the VST has returned this value, all future effEditOpen calls will be passed with an NSView * as the parameter, rather than a Carbon window. The plug-in must track whether it has received a "hasCockosViewAsConfig", and if it has returned the correct value. When adding a Cocoa UI, a plug-in should preferably add a single NSView to the passed NSView, via [(NSView *)ptr addSubview:myView] or similar.

The following are extensions made available to VST plug-ins running in REAPER. Feel free to use them in your plug-ins, and encourage other VST host developers to add support for them.

A REAPER aware VST plug-in can respond to effCanDo "hasCockosExtensions", with 0xbeef0000 (returning this value), which will inform the host that it can call certain extended calls.
A plug-in that responds to "hasCockosExtensions" may choose to implement any subset of the extended calls.

Gets the formatted display of a particular value for a parameter, without setting the parameter. REAPER uses this when displaying the value of a VST's automated parameter on an envelope tooltip, for example.

Converts the user's string to a normalized parameter value, without setting the parameter. Reaper uses this when the user is manually editing an envelope node, for example.
Calling with buf="" is a test for function availability.

audioMasterVendorSpecific(0xdeadbeef, audioMasterAutomate, listadjptr, 0.0)
Informs the host that the parameter list has changed dynamically (new parameters added or removed within the list), so the host can properly preserve existing automation and other mappings to higher numbered parameters.

The following are extensions made available to VST plug-ins running in REAPER. Feel free to use them in your plug-ins, and encourage other VST host developers to add support for them.

There are some additional functions to enable better integration with the host, the primary interface for accessing these extensions is via the audioMaster callback. Suppose your callback pointer is named "hostcb", then you would get each API with the following code:

If an API is not implemented, hostcb() will return 0, and the resulting function shouldn't be called. Except when noted, all functions can be called from any context in any thread at any time. A list of functions defined:

GetPlayPosition()

double (*GetPlayPosition)();

GetPlayPosition() returns the current playback position of the project. This is the time the user is hearing (and the transport shows etc). The value is in seconds.

GetPlayPosition2()

double (*GetPlayPosition2)();

GetPlayPosition() returns the current playback decode position of the project. This is the time of the audio block that is being processed by the host. The value is in seconds. This may be behind where your plug-in is processing, due to anticipative processing and/or PDC.

GetCursorPosition()

double (*GetCursorPosition)();

GetCursorPosition() returns the current edit cursor position (if any), in seconds.

SetEditCurPos() repositions the edit cursor to "time" (in seconds), optionally moving the view if necessary, and optionally seeking playback (if playing back). This function should ONLY be called from a UI context (i.e. from the editor window, NOT from audio processing etc).

GetSetRepeat()

int (*GetSetRepeat)(int parm);

GetSetRepeat() is used to change or query the transport "loop/repeat" state. Pass a parameter of -1 to query the repeat state, 0 to clear, 1 to set, and >1 to toggle. The return value is the new value of the repeat state. ONLY use this function to change the repeat state from the UI thread (however you can query safely at any time).

GetProjectPath()

void (*GetProjectPath)(char *buf, int bufsz);

GetProjectPath() can be used to query the path that media files are stored in for the current project.

These functions control the main transport for the host app. Only call these from the UI thread.

IsInRealTimeAudio()

int (*IsInRealTimeAudio)();

Returns nonzero if in the main audio thread, or in a thread doing synchronous multiprocessing. In these instances low latency is key. If this is 0, and you are in processReplacing, then you are being called in an anticipative processing thread.