Em sex., 4 de abr. de 2025 às 14:56, Alexandre Torres Porres <
por...@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/E7OWQEVFZXO7AQTAZFXP2XHZJ7UGFVZK/
>
>
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/SXLHJDZHKIIZNCXAJP6KE3FQKPCEQTZT/
