Installing on Macintosh computers
This is the README file for the “PureVST” VST3 plug-in. It tunnels Pure Data (Pd) inside any VST3 host such as a DAW. It is available either as source (which you have to compile yourself) or as a pre-compiled Macintosh VST3 plug-in (“Apple silicon” only; sorry, no Intel architecture yet) - or, experimentally, as a Fedora Linux Intel-architecture binary that might work on other linux distros but is untested. It should be possible to compile it for MacOs/Intel and Microsoft Windows as well but I haven’t tried these yet. You can get the source code and the compiled MacOS package on msp.ucsd.edu/tools/purevst .
You should be able to use it to run any Pure Data patch. The patch’s own audio inputs and outputs (dac~ and dac~ objects) appear as the plug-in’s own inputs and outputs. (Channels 1 and 2 are the main stereo in/out bus; nine other stereo “buses” are provided for up to 20 channels of input and output.) There are 64 VST “parameters” that generate messages to “param” in the Pd patch.
Incoming and outgoing MIDI “noteon” messages appear in the “notein”/“noteout” objects. Other MIDI messages are unimplemented (and Steinberg’s VST API is funny about them).
A new copy of PureVST starts up without any patch; you can open the Pd GUI and then open a patch within it. Each copy of PureVST remembers the location of the most recent patch that was saved (not loaded) within it, so just load and then save a patch, or else start a new patch from scratch, using Pd’s GUI within the plug-in.
The plug-in’s “VST GUI” pops up when you ask to open the plug-in within your DAW or other host. The GUI has controls for the first 10 VST “parameters”, plus a large ugly button which opens or closes Pd’s GUI. You need to install Pd as well as pureVST to use Pd’s GUI – see below.
Some of the capabilities of pureVST are demonstrated in the patch “test-patch.pd” which is included in the “resources” directory, or can be downloaded separately from the website.
PureVST is based on Pure Data (Pd), which itself contains two programs: a GUI program that users see, and a real-time program that does the actual work. PureVST uses the same GUI (and relies on an installed version of Pd to provide it) but has its own version of the real-time part, which, instead of opening audio devices and making noise on its own, routes its audio I/O through a VST host (such as a DAW) that it sits inside. In other words, the real-time program isn’t a standalone program but is instead a VST plug-in.
When you make an instance of PureVST it can run invisibly inside the host, and/or it can open the Pd GUI. This appears as a separate “application”. But in fact Pd itself - the real-time program - is running inside the host. IF there are two or more instances running with their GUIs open, these will appear as multiple copies of the Pd application running in parallel.
PureVST has a VST-style interface, which include an “OPEN” button - press this to open the Pd GUI. This GUI will only be present if you have Pd installed in a place that PureVST can find it - on Mac, this is either ~/Applications/Pd.app or /Applications/Pd.app and on linux it’s ~/pd/bin/pd .
Each instance of PureVST will ask the host (e.g., DAW) to remember which patch you most recently opened within it. (Although you can run several patches at a time, only the most recently opened one will be remembered). If you then do a “Save as” or save a new patch within PureVST, the new file location won’t automatically be remembered; if you do this, you can close and re-open the new file to get the host to reopen the correct file in the future. Since this is remembered by the host and not by PureVST itself, you will also have to save the host document to get the change noted. Different instances of PureVST can each load different patches.
An object is defined in Pd named “host” that the patch can send messages to. At the moment the most useful one is “read-uidesc” which reads an alternative UIDESC file. These can be generated using Steinberg’s “VST3 SDK” - or you can use the provided one as an example and build out from there. In principle you can use this feature to provide others with your patches that they can use with your GUI panels without their having to install Pd. The new GUI won’t take effect until the next time the VST panel is opened; you can put the message on a loadbang in the patch to be sure it’s loaded before the GUI gets opened the next time you load the plug-in.
The message “; host param 4 1 127 poodle” should change the name of VST parameter number 4 (counting from 0) to “poodle” and set its range as 0-127. Parameter 63 (the last one) is pre-named “OPEN” and you can use that to open and shut the GUI. (In Ableton, you can attach it to the stupid joystick to save a step having to open the VST GUI to open the Pd one).
NOTABLE LIMITATION: in order not to incur FIFO delays, PureVST expects the host to call it with a vector size that is either 64 or a multiple of 64. Most DAWs will do this by default, but I’ve heard that Reaper, if you ask it to loop a portion of its audio, can then call VSTs with truncated vector sizes. In these cases some of the input audio, up to 63 samples at a time, simply won’t be passed through PureVST and will come out unchanged from its input - you will probably hear this as a glitch in the audio.
REAPER: when the Pd GUI is open, Reaper believes it’s in the background. You can set a flag on Reaper to keep audio running while it’s in the background and this will allow you to open the Pd GUI without stopping audio. If you don’t do this there are some delays in getting Pd’s windows open and shut (you might have to pull Reaper into the foreground to get things to happen).
You can run PureVST on its own without its GUI (for instance, to package your own patch for someone else to use but not to see) - but for almost any other purpose you will want to install Pd as well as PureVST. Put Pd in your Applications folder or in the system one, and make sure it’s named “Pd.app” - not Pd-0.55-2.app or anything else.
Then download the compiled PureVST (PureVST.0.5.mac.tgz, for example) and extract the archive, creating a directory named “PureVST-0.5.vst3” (Your machine might only show the name as “PureVST”, hiding the “.vst3” part). Place this in either Library/Audio/Plug-Ins/VST3 within your home directory, or else in /Library/Audio/Plug-Ins/VST3 on your hard disk (doing that will require administrator permissions; anyway, it’s probably preferable to put it in your own directory.)
I am not a Macintosh “developer” so I can’t make officially signed binaries, so you will have to sign the goddam thing yourself. To do this, open a terminal window and type these magic commands:
codesign --force --sign - ~/Library/Audio/Plug-Ins/VST3/PureVST.vst3
xattr -d -r com.apple.quarantine \
~/Library/Audio/Plug-Ins/VST3/PureVST.vst3(The backslash at the end of the first line of the second command indicates to the terminal app that the following line is a continuation.) Then, if all has gone well, you can re-scan for new plug-ins (if your DAW needs that) and then find the new plug-in under the developer named “msp”.
Grab PureVST-0.5.fedora.tgz, unpack the archive, and place the result in your ~/.vst3 directory. This might work for other Linux distros too.
To do this you will need stuff: the Steinberg VST “SDK” (software development kit) and whatever compiler support they say you’ll want for your platform. On Macintosh that will mean Xcode and Cmake. On linux, the standard c and c++ compilers plus Cmake. On Windows nobody knows.
For any platform you will need the Pd source from May 24 2025 or later, as well as this pureVST source. You will first have to compile “libpd” from teh Pd sources, then pureVST. Ideally you should compile a special version of libpd that calls an additional extra function “vst_cleanser()” to help existing Pd externs run in pureVST’s threaded environment. The function is provided in the pureVST source, and so the makefile for libpd has to be told to include the extra source file. You can use the Makefile in […path-to…]/pd/libpd, with this command line:
make MORECFLAGS=-DVST_CLEANSER \
MORESRC=[...path-to...]/purevst/source/vst_cleanser.cThen using the PureVST source tree, consult the CMakeLists.txt file and correct the path settings for the VST SDK and for the Pd source. Then make an empty build directory, and using a shell or terminal window, change directory to the build directory and try to get these to work in sequence:
SRC=[...path-to...]/purevst
cmake -DCMAKE_BUILD_TYPE=Release \
-DSMTG_ENABLE_VST3_PLUGIN_EXAMPLES=FALSE \
-DSMTG_ENABLE_VST3_HOSTING_EXAMPLES=FALSE -DHOME=$HOME $SRCcmake --build .
(Note the backslashes in the second of the three commands which indicate that all three of the lines constitute a single command.)
The built VST should land somewhere in the build directory, perhaps under “VST3/Release”.
This will all, of course, WORK PERFECTLY THE FIRST TIME YOU TRY IT.
This software is copyrighted by Miller Puckette. The following terms (the “Standard Improved BSD License”) apply to all files associated with the software unless explicitly disclaimed in individual files:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS’’ AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.