What is this? How it works Installing on Macintosh computers Compiling from source BSD Copyright notice
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). It works on MacOS and on linux; 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 MIDI note messages generate messages to “midinote”.
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 (no 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 own “VST GUI” (which pops up with you ask to open the plug-in within your DAW or other host) has only one button, which opens or closes Pd’s GUI. Later on I want to make a facility for patches to add standard VST-style controllers to the VST GUI but this is for a future version of PureVST.
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 only shows 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 names “host” that the patch can send messages to. At the moment there’s only one defined message: “; host param 4 1 127 poodle” changes the name of VST parameter number 4 (counting from 0) to “poodle” and sets its range as 0-127. Parameter 63 (the last one) is pre-named “OPEN” and you can use that to programmatically 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.
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.1.tgz, for example) and extract the archive, creating a directory named “PureVST.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/pdv/PureVST.vst3
xattr -d -r com.apple.quarantine ~/Library/Audio/Plug-Ins/VST3/pdv/PureVST.vst3
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”.
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 Windows nobody knows.
For any platform you will need the Pd program, and also its source. Using the source, compile “libpd” using the Makefile in …/pd/libpd.
Then using the PureVST source tree, consult the CMakeLists.txt file and correct the path settings for the VST SDK and for Pd. Then make an empty build directory, and using a shell or terminal window, change directory to to the build directory and try to get these to work in sequence:
SRC=~/work/vst/purevst
[… or wherever the sources landed]
cmake -DCMAKE_BUILD_TYPE=Release -DSMTG_ENABLE_VST3_PLUGIN_EXAMPLES=FALSE -DSMTG_ENABLE_VST3_HOSTING_EXAMPLES=FALSE -DHOME=$HOME $SRC
cmake --build .
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.