Il Ven 4 Apr 2025, 19:56 Alexandre Torres Porres <[email protected]> ha scritto:
> > So, I will forward this thread to PlugData people and hopefully Tim or > someone else will be able to chime in. > > cheers > Tried here yesterday but probably isn't the right way and place https://discord.com/channels/993531159956955256/1036666275985891339/1357326113914753167 And @Miller Puckette <[email protected]> ..thanks for this new commitment...i'm thrilled to see where it will go! > > Em sex., 4 de abr. de 2025 às 10:32, Miller Puckette via Pd-dev < > [email protected]> 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 >> >> >> >> --- >> [email protected] - the Pd developers' mailinglist >> >> https://lists.iem.at/hyperkitty/list/[email protected]/message/E7OWQEVFZXO7AQTAZFXP2XHZJ7UGFVZK/ > > --- > [email protected] - the Pd developers' mailinglist > > https://lists.iem.at/hyperkitty/list/[email protected]/message/652MJ4QT7YA6LAMQYJVEY7IQ4XJOBBYG/
--- [email protected] - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/[email protected]/message/457DAQ234DHYBUXNYJJAONCIJGIRRTXX/
