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
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
... 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...
If I understand correctly both Camomile and PlugData require that any objects be compiled into the plug-in binary. 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.
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.
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...
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@list...
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__;!...
... 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...
<
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/7EDZMY54K4B...
On Fri, Apr 04, 2025 at 03:45:58PM -0300, Alexandre Torres Porres wrote:
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 :)
Absolutely. The day I can live code into a pd plugin while running in Ardour would be like a dream come true. Even if it requires a JIT compile that needs a button pushing and short delay. much encouragement, Andy
This already works for desktop libpd projects as long as libdl is linked.
On Apr 4, 2025, at 8:41 PM, Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
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...
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
That's right - my mistake. OTOH externs that use &s_, etc., won't be binary compatible and will need recompiling or fixing to avoid those symbols. This is probably less concerning than in the case of VST plug-ins where users might not have a compiler handy.
So I think I should just provide s_, etc., for VST plug-ins and no more broadly than that - other people making end-user apps with libpd can always do the same.
Meanwhile, c-language symbol clashes are still a problem. I've thought of a way one could edit, recompile and package externs so that they try first to bind to pd_class_new() and then failing that go back to class_new()... but the easier path is probably for me to release a pd vanilla 0.55-3 that provides the new symbols, so that it's at least possible to make an extern whose binary works in "stable" Pd but also in VSTs, and that won't need recompiling or repackaging for future Pds.
cheers Miller
On 4/4/25 10:28 PM, Dan Wilcox wrote:
This already works for desktop libpd projects as long as libdl is linked.
On Apr 4, 2025, at 8:41 PM, Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
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...
Dan Wilcox danomatika.com https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwOp0BXIw$ robotcowboy.com https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwHBNrcb6$
In the case of Ableton, it might be that Pd's extern functions are clashing with Max's coming from Max4Live. I thought there was a linker flag, at least on Windows, in order to deal with this that puts linked libs into a sort of different space, however that probably doesn't help in the case of externs trying to find the class functions.
Overall, I think prepending all such functions into a general "pd_" naming is the easiest and most correct long term solution, with fallback to classic naming. As established by Peter K, libpd took this route for all public functions. Even for such a storied project, it's cool to see Pd still has "growing pains" and is indicative that we still have new and interesting spaces to grow into ala "pd anywhere." ;)
I would suggest doing this with a Pd 0.56 release since IMO it would be the beginning of a major API change, even if such a release is really only bug fixes + this. IN the future, it would be easier to mark where this change came to know which precompile externs would still work and which not.
Another option, for compatibility, would be a completive define which exposes the original API after a hard transition is made.
On Apr 5, 2025, at 11:54 AM, Miller Puckette mpuckette@ucsd.edu wrote:
That's right - my mistake. OTOH externs that use &s_, etc., won't be binary compatible and will need recompiling or fixing to avoid those symbols. This is probably less concerning than in the case of VST plug-ins where users might not have a compiler handy.
So I think I should just provide s_, etc., for VST plug-ins and no more broadly than that - other people making end-user apps with libpd can always do the same.
Meanwhile, c-language symbol clashes are still a problem. I've thought of a way one could edit, recompile and package externs so that they try first to bind to pd_class_new() and then failing that go back to class_new()... but the easier path is probably for me to release a pd vanilla 0.55-3 that provides the new symbols, so that it's at least possible to make an extern whose binary works in "stable" Pd but also in VSTs, and that won't need recompiling or repackaging for future Pds.
cheers Miller
On 4/4/25 10:28 PM, Dan Wilcox wrote:
This already works for desktop libpd projects as long as libdl is linked.
On Apr 4, 2025, at 8:41 PM, Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
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...
Dan Wilcox danomatika.com https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwOp0BXIw$ robotcowboy.com https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwHBNrcb6$
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Em sáb., 5 de abr. de 2025 às 07:52, Dan Wilcox danomatika@gmail.com escreveu:
I would suggest doing this with a Pd 0.56 release since IMO it would be the beginning of a major API change, even if such a release is really only bug fixes + this.
+1!
That makes sense, and we already have some new features, like 'start or stop subprocess gui', new format specifiers for [makefilename] (%a/%A/%F), and some stuff for data structures I couldn't try and get yet. Maybe there's some more I don't know/remember, and I bet there are some lower hanging fruit to easily jam in a couple or more features (the 1-byte audio support you worked on comes to mind).
And the VST Support is simply hugely massive news ;)
While we're at it, I couldn't try it as I ran into some bugs, we should really have some apple signed download so it wouldn't be tagged as malware. I removed the quarantine flag via terminal and still couldn't load into Reaper. Audacity gave me an error and funnily enough I was able to load it inside MAX's trial version with their vst~ object. All I saw was an 'open' button that didn't seem to work.
I vote we should have a github repository for PureVST hosted in "pure-data" so we can easily report bugs and issues.
cheers
This is probably a diff but related topic:
I think we as a group really need to calm down on the "let's jam features in NOW" cycle. There should at least be a list made of what things are ready/important, perhaps in a Github issue, then we can clearly take a look at what makes sense to put into a possible BUGFIX 0.55.4 release and a larger 0.56 release (which IMO should have new features).
It's just not sustainable to keep adding new, possibly breaking stuff into bugfix release. I think the development model should really move to a develop branch which merges *changes / new stuff* and the master branch keeps bug fixes only. Newer features should also have enough time to be solidified in discussion and testing, although I realize most people (myself included) can't work on things all the time but in certain periods.
On Apr 5, 2025, at 1:20 PM, Alexandre Torres Porres porres@gmail.com wrote:
That makes sense, and we already have some new features, like 'start or stop subprocess gui', new format specifiers for [makefilename] (%a/%A/%F), and some stuff for data structures I couldn't try and get yet. Maybe there's some more I don't know/remember, and I bet there are some lower hanging fruit to easily jam in a couple or more features (the 1-byte audio support you worked on comes to mind).
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On that topic... I'm pretty careful about bugfix releases - I don't even try to fix bugs that don't look like show-stoppers, because I've sometimes created deeper, more subtle bugs in trying to fix obvious ones :) All that typically goes into 'master' so that it will make it in the next version (now 0.56).
In the past I've always identified master with the very-latest-maybe-buggy code, since that's the code I myself use in concerts. The advantage is that it forces me to keep things working most of the time... the disadvantage is that it makes me reluctant to embark on major changes like the one I'm working on now on data structures.
If it makes life easier for everyone else I could switch to a merge-into-master mode in which there's a rawhide branch that I'm personally using. But this might create more work since, if other PRs are getting merged into master, I'll also have to merge them into rawhide. I'm not sure what the best strategy would be.
Incidentally I'm planning to break my own rule to update 0.55 to be compatible with externs that use pd_class_new() so that people can compile externs that work both in 0.55 and in VSTs. That's more a compatibility enhancement than a bug fix. Other than that I don't have any changes planned for 0.55 - I'm focussed on 0.56 .
cheers Miller
On 4/5/25 2:46 PM, Dan Wilcox wrote:
This is probably a diff but related topic:
I think we as a group really need to calm down on the "let's jam features in NOW" cycle. There should at least be a list made of what things are ready/important, perhaps in a Github issue, then we can clearly take a look at what makes sense to put into a possible BUGFIX 0.55.4 release and a larger 0.56 release (which IMO should have new features).
It's just not sustainable to keep adding new, possibly breaking stuff into bugfix release. I think the development model should really move to a develop branch which merges *changes / new stuff* and the master branch keeps bug fixes only. Newer features should also have enough time to be solidified in discussion and testing, although I realize most people (myself included) can't work on things all the time but in certain periods.
On Apr 5, 2025, at 1:20 PM, Alexandre Torres Porres porres@gmail.com wrote:
That makes sense, and we already have some new features, like 'start or stop subprocess gui', new format specifiers for [makefilename] (%a/%A/%F), and some stuff for data structures I couldn't try and get yet. Maybe there's some more I don't know/remember, and I bet there are some lower hanging fruit to easily jam in a couple or more features (the 1-byte audio support you worked on comes to mind).
Dan Wilcox danomatika.com https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!EiVHWwjVG7aUiFOWzq4zet0CSLg3BsWZgwtrv7-dSzf7Zfguw6HrtzJ2BMZO1cCBbgWTYhBDPs_EBtc$ robotcowboy.com https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!EiVHWwjVG7aUiFOWzq4zet0CSLg3BsWZgwtrv7-dSzf7Zfguw6HrtzJ2BMZO1cCBbgWTYhBD9xYKCIU$
Am 5. April 2025 15:12:40 MESZ schrieb Miller Puckette via Pd-dev pd-dev@lists.iem.at:
Incidentally I'm planning to break my own rule to update 0.55 to be compatible with externs that use pd_class_new() so that people can compile externs that work both in 0.55 and in VSTs. That's more a compatibility enhancement than a bug fix.
personally I would: - start exporting `pd_class_new` as soon as possible (but without necessarily making it part of the public API as exposed in the headers) - LATER turn `class_new()` into a macro that points to `pd_class_new()` resp `pd_class_new64()`, depending on the floatsize. (similar to what we already do for Pd64).
"LATER" needs to take a while, so people can still run their newly compiled externals on older Pds.
I'm not overly enthusiastic about externals starting to explicitly use that new symbol.
mfg.sfg.jfd IOhannes
On Sat, 2025-04-05 at 15:12 +0200, Miller Puckette via Pd-dev wrote:
the disadvantage is that it makes me reluctant to embark on major changes like the one I'm working on now on data structures.
As a quick reminder: data structure are broken right now in current master, from what I can tell. They lost ability to register mouse clicks which was working up to 0.55-2.
https://github.com/pure-data/pure-data/issues/2514
(sorry for thread-hijacking)
Roman
I bet you're right about Pd clashing with Max - I shoulda thought of that :)
Anyway, prepending pd_ to every function in m_pd.h (and offering the old names for binary back compatibilty) sounds like too high a mountain to climb to me. For the moment I'm thinking of just working on the known (or most likely) clashes.
Likely reason you couldn't get Pd's GUI to pop up is that pureVST only looks in certain locations for Pd itself, such as ~/Applications/Pd.app. I should make a "glob" thing to look for "Pd-*.app" but haven't got to that yet - in the meantime just rename or copy Pd tp Pd.app.
cheers Miller
On 4/5/25 12:52 PM, Dan Wilcox wrote:
In the case of Ableton, it might be that Pd's extern functions are clashing with Max's coming from Max4Live. I thought there was a linker flag, at least on Windows, in order to deal with this that puts linked libs into a sort of different space, however that probably doesn't help in the case of externs trying to find the class functions.
Overall, I think prepending all such functions into a general "pd_" naming is the easiest and most correct long term solution, with fallback to classic naming. As established by Peter K, libpd took this route for all public functions. Even for such a storied project, it's cool to see Pd still has "growing pains" and is indicative that we still have new and interesting spaces to grow into ala "pd anywhere." ;)
I would suggest doing this with a Pd 0.56 release since IMO it would be the beginning of a major API change, even if such a release is really only bug fixes + this. IN the future, it would be easier to mark where this change came to know which precompile externs would still work and which not.
Another option, for compatibility, would be a completive define which exposes the original API after a hard transition is made.
On Apr 5, 2025, at 11:54 AM, Miller Puckette mpuckette@ucsd.edu wrote:
That's right - my mistake. OTOH externs that use &s_, etc., won't be binary compatible and will need recompiling or fixing to avoid those symbols. This is probably less concerning than in the case of VST plug-ins where users might not have a compiler handy.
So I think I should just provide s_, etc., for VST plug-ins and no more broadly than that - other people making end-user apps with libpd can always do the same.
Meanwhile, c-language symbol clashes are still a problem. I've thought of a way one could edit, recompile and package externs so that they try first to bind to pd_class_new() and then failing that go back to class_new()... but the easier path is probably for me to release a pd vanilla 0.55-3 that provides the new symbols, so that it's at least possible to make an extern whose binary works in "stable" Pd but also in VSTs, and that won't need recompiling or repackaging for future Pds.
cheers Miller
On 4/4/25 10:28 PM, Dan Wilcox wrote:
This already works for desktop libpd projects as long as libdl is linked.
On Apr 4, 2025, at 8:41 PM, Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
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...
Dan Wilcox danomatika.com https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwOp0BXIw$ robotcowboy.com https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!DLYqLdlNz2mWdUR0rCMmFhrz-1mZkad-bvOzMhljIHb92ehrsjst63rBXbNW7Vf5ImDYaxZoAfyXwHBNrcb6$
Dan Wilcox danomatika.com https://urldefense.com/v3/__http://danomatika.com__;!!Mih3wA!BEHkKVNOi2yg2MM6rOoYOTniDJ60vPp6NIJblsghYyoBJtgYLJSQHtcRoqvoYud8g6QkiC6XxmIuazs$ robotcowboy.com https://urldefense.com/v3/__http://robotcowboy.com__;!!Mih3wA!BEHkKVNOi2yg2MM6rOoYOTniDJ60vPp6NIJblsghYyoBJtgYLJSQHtcRoqvoYud8g6QkiC6XZgkQhdg$
Il Ven 4 Apr 2025, 19:56 Alexandre Torres Porres porres@gmail.com 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/13573261...
And @Miller Puckette msp@ucsd.edu ..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 < 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...
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/652MJ4QT7YA...
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...
Late to the party...
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.
As you have found out in the meantime, these symbols come from Max4Live :)
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:
You can! If you dlopen() the externals with RTLD_DEEPBIND they should look in the dynamic library itself and its dependencies (= libpd) before taking the symbol from the global namespace. Give it a try!
If you can remember, we had a similar problem with [vstplugin~] when you tried to test Camomile VST plugins inside Pd with [vstplugin~]. You got a clash between the symbols of the main Pd application and the libpd symbols from Camomile. My fix was to I dlopen() the VST plugins with RTLD_NOW | RTLD_DEEPBIND: https://git.iem.at/pd/vstplugin/-/blob/master/vst/Module.cpp?ref_type=heads#...
---
On Windows you don't have this problem because symbols use a DLL-level namespace and there is no global symbol table. I thought that macOS also uses symbol namespaces. Does your issue really occur on macOS too?
Christof