Hi all-- first time posting here, please let me know if I'm doing it wrong.
I've been trying to compile PureVST 0.3 natively for Windows (using Visual Studio 17 2022 for my compiler-- MSVC) and there seems to be a set of macros and headers that the Windows doesn't like (not surprising!). Namely, in pdprocessor.cpp, it doesn't like <dlfcn.h>.
One can patch in a fix using this handy Windows rewrite of dlfcn.h<https://github.com/dlfcn-win32/dlfcn-win32>, though a bunch more linker errors pop up on the build step that involves the Pd source. I compiled the Pd source using the Makefile within MinGW, though since we're using MSVC for PureVST, it seems to have compatibility issues with the includes. Here's a Pastebin<https://pastebin.com/PxaaUvZX> of my Command Prompt.
All in all, I have tried: using MinGW for Pd source and MSVC for PureVST (linker errors when building PureVST), using MSVC for both Pd source and PureVST (fails to compile Pd source), using MinGW for both Pd source and PureVST (fails to compile VST SDK-- though there is this<https://github.com/perivar/vstsdk>, and it seems promising, though I don't know enough CMake to get it working), and using WSL for everything (compiles to a Linux VST, which isn't compatible with Windows DAWs).
I was wondering if any other Windows people have gone through this process and have found a fix. Seems like I've hit a wall here.
Any advice would be greatly appreciated!
Best,
Ian Doherty
UIUC CS+Music '25
ied2(a)illinois.edu
To Pd dev -
I'm having fun seing if I can run large patches inside DAWs using the
purevst plug-in, and have hit one problem that I don't know how to deal
with, both technically and as a design question. Large patches (such as
Philippe Manoury's upcoming opera :) typically have to fall back on
externs for one thing or another. In Manoury's case, that would be
vstplugin~, smerdyakov, and antescofo~. (It's humorous that I'm having
to run vstplugin~ _inside a VST plugin_ but there it is. FWIW the
reverse - loading purevst under vstplugin~ - is working for me.)
I found two problems loading externs into purevst... first off,
pre-defined symbols such as s_float are defined as globals in Pd but as
per-instance objects in libpd. This means that externs compiled for Pd
that use those symbols won't load (dynamic linking says s__float is
undefined). Of course we could just recompile every Pd extern in teh
world to always use gensym("float") instead of s_float, but this might
take a decade to do. Another solution would be for me to define
s__float, etc., as static globals inside libpd but just never use them;
then when an un-hip extern sends them to pd_bind or class_addmethod or
the like I could just catch it and replace with the libpd-defined
version. This might be error-prone but might be worth doing as a stopgap.
But the bigger problem is this... running inside Ableton I found out
that the functions class_new(), class_addmethod(), and post() get
resolved to something other than the libpd-supplied ones - there's
apparently a name clash with some dynamic library or other that Ableton
Live links to. I can't find any way I can control the order in which
dynamic linking under MacOS or linux resolves symbols. I did get
pointed to one fun article here:
https://www.akkadia.org/drepper/dsohowto.pdf
... but I can't find any way yet to oblige a Pd extern to call Pd's
version of class_new() instead of someone else's.
The upshot is that Pd externs might load OK under some DAWs and crash in
others. They're all guaranteed to fail in Ableton, and sometimes
manage to crash it.
So... I could provide new functions pd_class_new() etc. Externs that
called the new functions wouldn't load in existing versions of Pd, so to
get an extern to run in either Pd vanilla or in libpd, you'd have to do
a run-time link to the new functions and revert to the old ones if the
new ones aren't found. And, as new conflicts arise in the future, this
will have to be done to more ane more functions.
Anyone with a better idea please let me in on it :)
Miller
To Pd dev -
I've uploaded another version, 0.2, to the same old
msp.ucsd.edu/tools/purevst .
(I tried to set up a github project but couldn't figure out how to get
permission to push my local repo to it. Giving up on that for now.)
The main thing that now needs thinking through is what to do for a
standard VST3 interface - there shuold be some way for the patch to put
controls on the VST3 surface, perhaps using Steinberg's own GUI-building
nonsense in some way so that things look like a normal VST if you don't
get around to opening the Pd GUI.
cheers
Miller