Em sex., 4 de abr. de 2025 às 15:41, Miller Puckette via Pd-dev <
pd-dev@lists.iem.at> escreveu:
If I understand correctly both Camomile and PlugData require that any
objects be compiled into the plug-in binary.
That's true, but the hack is when you have a pd patch that opens your regular Pd application via the [pd~] object.
What I'm looking for is
something that can load external objects dynamically, so that you can
take any working Pd patch and just drop it, externs and all, into your DAW.
Yup, so that is what camomile's last unreleased version was achieving. There's a demo video somewhere but I can't find it now.
And yes, one way to do that is just to use pureVST to load a patch with
a pd~ object and some glue to connect parameter changes and MIDI in and
out. But that will come with FIFO delays of at least a couple of
milliseconds, and if you put a few such plug-ins in series that will
start to add up.
hmmm, I think I see.
My longer-term hope is to be able to load externs dynamically into
either Pd or libpd without having to compile separately for the two
situations...
wow, that would be amazing, total game changer, I see it now :)
cheers
Miller
On 4/4/25 7:56 PM, Alexandre Torres Porres wrote:
> Hi, I certainly can't follow this, but I just wanted to point out that
> PlugData is based on libpd and runs Pd with some externals just fine
> in any DAW (including Ableton Live), so maybe they have a good
> perspective to share.
>
> Also, PlugData was based on the now rather long abandoned camomile
> project. In its last unreleased version, you could load Pd Vanila into
> any DAW via a simple patch that was just using [pd~] object, so it
> would run Pd with any of your installed externals in the Pd subprocess.
>
> PlugData hasn't yet quite resolved the [pd~] object I think, but it
> would be great if we could all just use PlugData and use a simple
> patch to open Pd Vanilla via the [pd~] object and everything would
> just work.
>
> So this is what I think it should be a better idea, or perhaps a new
> minimal version of PlugData that simply uses the [pd~] object to open
> Pd Vanilla. I would totally use that and it would even discard the
> need of PlugData for me personally. 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~] ;)
>
> 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
> <https://urldefense.com/v3/__https://www.akkadia.org/drepper/dsohowto.pdf__;!!Mih3wA!Gc5GHhZDmAE_FGtj1IIotVk_oePNQhrn20jKXuYLsosPc2Tu9C6PiSvluy3og8bKzqNGgZnF7w$>
>
> ... 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/E7OWQEVFZXO7AQTAZFXP2XHZJ7UGFVZK/
> <https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/E7OWQEVFZXO7AQTAZFXP2XHZJ7UGFVZK/__;!!Mih3wA!Gc5GHhZDmAE_FGtj1IIotVk_oePNQhrn20jKXuYLsosPc2Tu9C6PiSvluy3og8bKzqNX73537Q$>
>
>
> ---
> pd-dev@lists.iem.at - the Pd developers' mailinglist
> https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/652MJ4QT7YA6LAMQYJVEY7IQ4XJOBBYG/__;!!Mih3wA!Gc5GHhZDmAE_FGtj1IIotVk_oePNQhrn20jKXuYLsosPc2Tu9C6PiSvluy3og8bKzqMSG_3GDQ$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/7EDZMY54K4BPVENGRDGCBT56USQAPL2Z/