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/
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/J4WO2U7I2ZF7ZDTBXRMDOFCWHV2QVTGU/
