Em sex., 4 de abr. de 2025 às 14:56, Alexandre Torres Porres < porres@gmail.com> escreveu:
We could have a new VST wrapper around Pd that is just that, and it'd be like having the [pd~] external from MAX, but it would let you run Pd in any DAW instead. Call it "Vanilla Plug" (even though "plug" and "vanilla" don't come often in the same sentence). And yeah, we would be able to use Pd as a plugin using [vstplugin~] ;)
This pd-dev email came later, so I read it before checking the earlier ones, like the pd-announce mail about PureVST :) and I thought we were talking about a plugin that already existed. Now I see we're talking about a new thing and it's exactly what I wanted, so it seems :)
Sorry about the confusion, I will try and check it as soon as I can ;)
Wow, I'm really excited about this!
Thanks
So, I will forward this thread to PlugData people and hopefully Tim or someone else will be able to chime in.
cheers
Em sex., 4 de abr. de 2025 às 10:32, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
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
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/E7OWQEVFZXO...