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