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 VST3 plug-in for Macintosh computers (“Apple silicon” only; sorry, no Intel architecture yet) - or as a Fedora or Ubuntu linux Intel-architecture binary that might work on some other linux distros as well. It should be possible to compile PureVST 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 .
Cool feature: you can display and even edit the Pd patch within the VST while it is running, without adding latency; the Pd GUI is a separate process but Pd itself runs inside the DAW. You will need to install Pd as well as pureVST to use Pd’s GUI (for instance, to “open” or edit a patch) – see below.
You should be able to use PureVST to run any Pure Data patch,
although not all “externs” will work (see below). 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.
Your patch can send messages to the “host” object to display parameter changes and/or (Mac only so far) to rename parameters so that the DAW sees your names. The message “host param 0 0.5” for instance sets the value of the first parameter to 0.5 in the DAW. To name it, for instance, you can send “define-param 21 108 0 fred” to set the first parameter (number 0) to use the parameter name “fred” and to range from 21 to 108.
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.9.mac.zip, for example) and extract the archive, creating a MacOS “package” which you then click on. It offers to install either for all users or for you alone. I do the latter and then I look in ~/Library/Audio/Plug-Ins/VST3 to see if there is a directory “PureVST.vst3” there.
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.9.fedora.tgz or PureVST-0.9.ubuntu.tgz, unpack the archive, and place the result in your ~/.vst3 directory. The “ubuntu” version might work also on Debian - I haven’t tried that yet.
Many but not all external objects will work without requiring recompilation. However, there is an unfortunate name clash between Pd and Ableton that will cause trouble loading pre-existing externs into Ableton Live. In any situation where your favorite extern can’t run in PureVST, you should be able to use the pd~ object inside the PureVST’s Pd patch to sprout a new Pd process that will do everything as if it were Pd as its own app. Note that you’ll have to supply “-pddir” and “-scheddir” arguemnts to pd~ to point it to the “real” Pd app you want to run. N.B.: this will add latency, which PureVST in itself does not.
Follow the instructions in the file “INSTALL.txt” to compile your own PureVST.
Thanks to Pierre Guillot for invaluable help dealing with MacOS foofoo.
This work is supported by IRCAM and UCSD.
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.