I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway.
On Mar 30, 2022, at 5:40 PM, pd-dev-request@lists.iem.at wrote:
Message: 1 Date: Wed, 30 Mar 2022 16:06:23 +0200 From: IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] call for discussion double-precision file extension Message-ID: <3a9d2e07-a831-eb18-7797-5ff5b191e0b4@iem.at mailto:3a9d2e07-a831-eb18-7797-5ff5b191e0b4@iem.at> Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 3/29/22 20:26, Sebastian Shader via Pd-dev wrote:
I wonder if anything should be considered for multi-instance support as well (externals compiled w/ PDINSTANCE)
good question.
afaict, there are no plans to ever ship binaries Pd with PDINSTANCE=1 (but i have no idea, really).
can we expect developers of PDINSTANCE-enabled (lib)Pds to also provide the binaries for the extrenals? i guess it would be nice if you (as a patch-developer with a compiler-allergy) could just install whatever externals you want to be included with your camomille-based VST plugin.
gfmdras IOhannes
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 3/30/22 17:45, Dan Wilcox wrote:
I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway.
i wonder what the penalty would be to turn on PDINSTANCE on Pd?
obviously a problem with externals, but maybe we can come up with some clever hack (under the assumption, that Pd (the app) only runs a single instance, even if compiled with multi-instance support) to use legacy externals - if that is even possible.
apart from that?
fgadrms IOhannes
AFAICT, the main issue is that multi-instance Pd misses symbols for certain global variables, most notably s_float, s_symbol, s_bang, etc.
The problem is that these are really exported global structs. If they were *pointers*, we could simply make them point to the corresponding field in the main Pd instance. But in this case I don't really see a solution...
On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
On 3/30/22 17:45, Dan Wilcox wrote:
I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway.
i wonder what the penalty would be to turn on PDINSTANCE on Pd?
obviously a problem with externals, but maybe we can come up with some clever hack (under the assumption, that Pd (the app) only runs a single instance, even if compiled with multi-instance support) to use legacy externals - if that is even possible.
apart from that?
fgadrms IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I very much agree that in the future Pd (and externals) could be always compiled with PDINSTANCE.
I was thinking to a way for the transition: we could: - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_* replacement macros accordingly), - export "hidden" globals s_* - initialize pd_maininstance pd_s_* fields to the global versions.
CURRENT: /* m_pd.h */ struct _pdinstance { t_symbol pd_s_float; } #define s_float (pd_this->pd_s_float)
/* m_class.c */ t_pdinstance *pdinstance_init(t_pdinstance *x) { dogensym("float", &x->pd_s_float, x); }
PROPOSAL: /* m_pd.h */ struct _pdinstance { t_symbol *pd_s_float; } #define s_float (*(pd_this->pd_s_float))
/* m_class.c */ #undef s_float t_symbol s_float; t_pdinstance *pdinstance_init(t_pdinstance *x) { if(x != &pd_maininstance) x->pd_s_float = gensym("float"); else { dogensym("float", &s_float, x); x->pd_s_float = &s_float; }
What do you think?
I've tried this (in libpd context) almost successfully, but I've encountered a problem: the s_float as seen from an app linked to libpd seems to be uninitialized. I've tried something simpler: /* m_class.c */ float myfloat = 10.0; t_pdinstance *pdinstance_init(t_pdinstance *x) { myfloat = 20.0; printf("pdinstance_init::myfloat: %f\n", myfloat); }
/* pdtest.c */ extern float myfloat; int main() { libpd_init(); printf("myfloat: %f\n", myfloat); }
cc -I../../../libpd_wrapper -I../../../pure-data/src -O3 -c -o pdtest.o pdtest.c gcc -o pdtest pdtest.o ../../../libs/libpd.so
$ pdtest pdinstance_init::myfloat: 20.00000 myfloat: 10.00000
Do you know why pdtest doesn't see the updated value?
Le mer. 30 mars 2022 à 23:51, Christof Ressi info@christofressi.com a écrit :
AFAICT, the main issue is that multi-instance Pd misses symbols for certain global variables, most notably s_float, s_symbol, s_bang, etc.
The problem is that these are really exported global structs. If they were *pointers*, we could simply make them point to the corresponding field in the main Pd instance. But in this case I don't really see a solution...
On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
On 3/30/22 17:45, Dan Wilcox wrote:
I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway.
i wonder what the penalty would be to turn on PDINSTANCE on Pd?
obviously a problem with externals, but maybe we can come up with some clever hack (under the assumption, that Pd (the app) only runs a single instance, even if compiled with multi-instance support) to use legacy externals - if that is even possible.
apart from that?
fgadrms IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
Yes, this would work. Of course, it would be an ABI break for multi-instance libpd, but I think it would be justified. I guess libpd users rarely rely on pre-build externals, and even if they do, I think it's ok to ask them to recompile.
We should probably also put the global s_* symbols in a deprecation macro that tells external authors to use gensym() instead.
Christof
On 04.04.2022 13:55, Antoine Rousseau wrote:
I very much agree that in the future Pd (and externals) could be always compiled with PDINSTANCE.
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
CURRENT: /* m_pd.h */ struct _pdinstance { t_symbol pd_s_float; } #define s_float (pd_this->pd_s_float)
/* m_class.c */ t_pdinstance *pdinstance_init(t_pdinstance *x) { dogensym("float", &x->pd_s_float, x); }
PROPOSAL: /* m_pd.h */ struct _pdinstance { t_symbol *pd_s_float; } #define s_float (*(pd_this->pd_s_float))
/* m_class.c */ #undef s_float t_symbol s_float; t_pdinstance *pdinstance_init(t_pdinstance *x) { if(x != &pd_maininstance) x->pd_s_float = gensym("float"); else { dogensym("float", &s_float, x); x->pd_s_float = &s_float; }
What do you think?
I've tried this (in libpd context) almost successfully, but I've encountered a problem: the s_float as seen from an app linked to libpd seems to be uninitialized. I've tried something simpler: /* m_class.c */ float myfloat = 10.0; t_pdinstance *pdinstance_init(t_pdinstance *x) { myfloat = 20.0; printf("pdinstance_init::myfloat: %f\n", myfloat); }
/* pdtest.c */ extern float myfloat; int main() { libpd_init(); printf("myfloat: %f\n", myfloat); }
cc -I../../../libpd_wrapper -I../../../pure-data/src -O3 -c -o pdtest.o pdtest.c gcc -o pdtest pdtest.o ../../../libs/libpd.so
$ pdtest pdinstance_init::myfloat: 20.00000 myfloat: 10.00000
Do you know why pdtest doesn't see the updated value?
Le mer. 30 mars 2022 à 23:51, Christof Ressi info@christofressi.com a écrit :
AFAICT, the main issue is that multi-instance Pd misses symbols for certain global variables, most notably s_float, s_symbol, s_bang, etc. The problem is that these are really exported global structs. If they were *pointers*, we could simply make them point to the corresponding field in the main Pd instance. But in this case I don't really see a solution... On 30.03.2022 18:07, IOhannes m zmoelnig wrote: > > On 3/30/22 17:45, Dan Wilcox wrote: >> I lean much more on the side that PDINSTANCE is a low-level, per >> project compile option and not general-purpose. If you are using >> libpd, then your environment is a bit more custom anyway. > > i wonder what the penalty would be to turn on PDINSTANCE on Pd? > > > obviously a problem with externals, but maybe we can come up with some > clever hack (under the assumption, that Pd (the app) only runs a > single instance, even if compiled with multi-instance support) to use > legacy externals - if that is even possible. > > apart from that? > > fgadrms > IOhannes > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at > https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Unfortunately, I see another, more subtle problem:
Let's assume an external uses helper threads that call Pd API functions. With PDINSTANCE, it must explicitly call /pd_setinstance()/ on each thread to set the appropriate Pd instance, otherwise it would crash (because /pd_this /would be///NULL/).
Usually, helper threads do not call Pd API functions, but I can think of at least one major exception: logging!
In my own code, I sometimes do:
sys_lock(); pd_error(x, "some critical error I absolutely want the user to see"); sys_unlock();
If this external is compiled /without /PDINSTANCE, but Pd is built /with /PDINSTANCE, the external will load properly, but crash on runtime.
There are other cases where an external might want to behave differently depending on whether PDINSTANCE is defined or not. For example: https://git.iem.at/pd/vstplugin/-/blob/master/pd/src/vstplugin~.cpp
Of course, such externals would just need to be recompiled, but it is something to be aware of.
---
Conclusion: "secretly" enabling PDINSTANCE for regular Pd builds can break existing externals in unexpected ways.
Christof
On 04.04.2022 15:00, Christof Ressi wrote:
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the
s_* replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
Yes, this would work. Of course, it would be an ABI break for multi-instance libpd, but I think it would be justified. I guess libpd users rarely rely on pre-build externals, and even if they do, I think it's ok to ask them to recompile.
We should probably also put the global s_* symbols in a deprecation macro that tells external authors to use gensym() instead.
Christof
On 04.04.2022 13:55, Antoine Rousseau wrote:
I very much agree that in the future Pd (and externals) could be always compiled with PDINSTANCE.
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the
s_* replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
CURRENT: /* m_pd.h */ struct _pdinstance { t_symbol pd_s_float; } #define s_float (pd_this->pd_s_float)
/* m_class.c */ t_pdinstance *pdinstance_init(t_pdinstance *x) { dogensym("float", &x->pd_s_float, x); }
PROPOSAL: /* m_pd.h */ struct _pdinstance { t_symbol *pd_s_float; } #define s_float (*(pd_this->pd_s_float))
/* m_class.c */ #undef s_float t_symbol s_float; t_pdinstance *pdinstance_init(t_pdinstance *x) { if(x != &pd_maininstance) x->pd_s_float = gensym("float"); else { dogensym("float", &s_float, x); x->pd_s_float = &s_float; }
What do you think?
I've tried this (in libpd context) almost successfully, but I've encountered a problem: the s_float as seen from an app linked to libpd seems to be uninitialized. I've tried something simpler: /* m_class.c */ float myfloat = 10.0; t_pdinstance *pdinstance_init(t_pdinstance *x) { myfloat = 20.0; printf("pdinstance_init::myfloat: %f\n", myfloat); }
/* pdtest.c */ extern float myfloat; int main() { libpd_init(); printf("myfloat: %f\n", myfloat); }
cc -I../../../libpd_wrapper -I../../../pure-data/src -O3 -c -o pdtest.o pdtest.c gcc -o pdtest pdtest.o ../../../libs/libpd.so
$ pdtest pdinstance_init::myfloat: 20.00000 myfloat: 10.00000
Do you know why pdtest doesn't see the updated value?
Le mer. 30 mars 2022 à 23:51, Christof Ressi info@christofressi.com a écrit :
AFAICT, the main issue is that multi-instance Pd misses symbols for certain global variables, most notably s_float, s_symbol, s_bang, etc. The problem is that these are really exported global structs. If they were *pointers*, we could simply make them point to the corresponding field in the main Pd instance. But in this case I don't really see a solution... On 30.03.2022 18:07, IOhannes m zmoelnig wrote: > > On 3/30/22 17:45, Dan Wilcox wrote: >> I lean much more on the side that PDINSTANCE is a low-level, per >> project compile option and not general-purpose. If you are using >> libpd, then your environment is a bit more custom anyway. > > i wonder what the penalty would be to turn on PDINSTANCE on Pd? > > > obviously a problem with externals, but maybe we can come up with some > clever hack (under the assumption, that Pd (the app) only runs a > single instance, even if compiled with multi-instance support) to use > legacy externals - if that is even possible. > > apart from that? > > fgadrms > IOhannes > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at > https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
ABI break for multi-instance libpd
only externals already compiled for multi-instance would have to be recompiled, I think. And it wouldn't allow current externals to be used in a multi-instance context.
But it would allow a Pd compiled with PDINSTANCE, or a single-instance libpd app compiled with PDINSTANCE to load current externals (compiled without PDINSTANCE).
Antoine
Le lun. 4 avr. 2022 à 15:00, Christof Ressi info@christofressi.com a écrit :
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
Yes, this would work. Of course, it would be an ABI break for multi-instance libpd, but I think it would be justified. I guess libpd users rarely rely on pre-build externals, and even if they do, I think it's ok to ask them to recompile.
We should probably also put the global s_* symbols in a deprecation macro that tells external authors to use gensym() instead.
Christof On 04.04.2022 13:55, Antoine Rousseau wrote:
I very much agree that in the future Pd (and externals) could be always compiled with PDINSTANCE.
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
CURRENT: /* m_pd.h */ struct _pdinstance { t_symbol pd_s_float; } #define s_float (pd_this->pd_s_float)
/* m_class.c */ t_pdinstance *pdinstance_init(t_pdinstance *x) { dogensym("float", &x->pd_s_float, x); }
PROPOSAL: /* m_pd.h */ struct _pdinstance { t_symbol *pd_s_float; } #define s_float (*(pd_this->pd_s_float))
/* m_class.c */ #undef s_float t_symbol s_float; t_pdinstance *pdinstance_init(t_pdinstance *x) { if(x != &pd_maininstance) x->pd_s_float = gensym("float"); else { dogensym("float", &s_float, x); x->pd_s_float = &s_float; }
What do you think?
I've tried this (in libpd context) almost successfully, but I've encountered a problem: the s_float as seen from an app linked to libpd seems to be uninitialized. I've tried something simpler: /* m_class.c */ float myfloat = 10.0; t_pdinstance *pdinstance_init(t_pdinstance *x) { myfloat = 20.0; printf("pdinstance_init::myfloat: %f\n", myfloat); }
/* pdtest.c */ extern float myfloat; int main() { libpd_init(); printf("myfloat: %f\n", myfloat); }
cc -I../../../libpd_wrapper -I../../../pure-data/src -O3 -c -o pdtest.o pdtest.c gcc -o pdtest pdtest.o ../../../libs/libpd.so
$ pdtest pdinstance_init::myfloat: 20.00000 myfloat: 10.00000
Do you know why pdtest doesn't see the updated value?
Le mer. 30 mars 2022 à 23:51, Christof Ressi info@christofressi.com a écrit :
AFAICT, the main issue is that multi-instance Pd misses symbols for certain global variables, most notably s_float, s_symbol, s_bang, etc.
The problem is that these are really exported global structs. If they were *pointers*, we could simply make them point to the corresponding field in the main Pd instance. But in this case I don't really see a solution...
On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
On 3/30/22 17:45, Dan Wilcox wrote:
I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway.
i wonder what the penalty would be to turn on PDINSTANCE on Pd?
obviously a problem with externals, but maybe we can come up with some clever hack (under the assumption, that Pd (the app) only runs a single instance, even if compiled with multi-instance support) to use legacy externals - if that is even possible.
apart from that?
fgadrms IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing listPd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 04.04.2022 15:49, Antoine Rousseau wrote:
ABI break for multi-instance libpdonly externals already compiled for multi-instance would have to be recompiled, I think.
That's what I meant.
And it wouldn't allow current externals to be used in a multi-instance context.
But it would allow a Pd compiled with PDINSTANCE, or a single-instance libpd app compiled with PDINSTANCE to load current externals (compiled without PDINSTANCE).
Exactly.
(sorry, too long mail polling, your answer came after my previous one)
cases where an external might want to behave differently depending on
whether PDINSTANCE is defined or not
yes you're right... I remember I helped to fix readsf~/writesf~ for multi-instance / multi-thread context, by adding *pd_setinstance() *in the helper threads. so I agree with your conclusion. Things will have to be prepared carefully...
Le lun. 4 avr. 2022 à 15:49, Antoine Rousseau antoine@metalu.net a écrit :
ABI break for multi-instance libpd
only externals already compiled for multi-instance would have to be recompiled, I think. And it wouldn't allow current externals to be used in a multi-instance context.
But it would allow a Pd compiled with PDINSTANCE, or a single-instance libpd app compiled with PDINSTANCE to load current externals (compiled without PDINSTANCE).
Antoine
Le lun. 4 avr. 2022 à 15:00, Christof Ressi info@christofressi.com a écrit :
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
Yes, this would work. Of course, it would be an ABI break for multi-instance libpd, but I think it would be justified. I guess libpd users rarely rely on pre-build externals, and even if they do, I think it's ok to ask them to recompile.
We should probably also put the global s_* symbols in a deprecation macro that tells external authors to use gensym() instead.
Christof On 04.04.2022 13:55, Antoine Rousseau wrote:
I very much agree that in the future Pd (and externals) could be always compiled with PDINSTANCE.
I was thinking to a way for the transition: we could:
- change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
replacement macros accordingly),
- export "hidden" globals s_*
- initialize pd_maininstance pd_s_* fields to the global versions.
CURRENT: /* m_pd.h */ struct _pdinstance { t_symbol pd_s_float; } #define s_float (pd_this->pd_s_float)
/* m_class.c */ t_pdinstance *pdinstance_init(t_pdinstance *x) { dogensym("float", &x->pd_s_float, x); }
PROPOSAL: /* m_pd.h */ struct _pdinstance { t_symbol *pd_s_float; } #define s_float (*(pd_this->pd_s_float))
/* m_class.c */ #undef s_float t_symbol s_float; t_pdinstance *pdinstance_init(t_pdinstance *x) { if(x != &pd_maininstance) x->pd_s_float = gensym("float"); else { dogensym("float", &s_float, x); x->pd_s_float = &s_float; }
What do you think?
I've tried this (in libpd context) almost successfully, but I've encountered a problem: the s_float as seen from an app linked to libpd seems to be uninitialized. I've tried something simpler: /* m_class.c */ float myfloat = 10.0; t_pdinstance *pdinstance_init(t_pdinstance *x) { myfloat = 20.0; printf("pdinstance_init::myfloat: %f\n", myfloat); }
/* pdtest.c */ extern float myfloat; int main() { libpd_init(); printf("myfloat: %f\n", myfloat); }
cc -I../../../libpd_wrapper -I../../../pure-data/src -O3 -c -o pdtest.o pdtest.c gcc -o pdtest pdtest.o ../../../libs/libpd.so
$ pdtest pdinstance_init::myfloat: 20.00000 myfloat: 10.00000
Do you know why pdtest doesn't see the updated value?
Le mer. 30 mars 2022 à 23:51, Christof Ressi info@christofressi.com a écrit :
AFAICT, the main issue is that multi-instance Pd misses symbols for certain global variables, most notably s_float, s_symbol, s_bang, etc.
The problem is that these are really exported global structs. If they were *pointers*, we could simply make them point to the corresponding field in the main Pd instance. But in this case I don't really see a solution...
On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
On 3/30/22 17:45, Dan Wilcox wrote:
I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway.
i wonder what the penalty would be to turn on PDINSTANCE on Pd?
obviously a problem with externals, but maybe we can come up with some clever hack (under the assumption, that Pd (the app) only runs a single instance, even if compiled with multi-instance support) to use legacy externals - if that is even possible.
apart from that?
fgadrms IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing listPd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Antoine Rousseau -
Christof Ressi -
Dan Wilcox -
IOhannes m zmoelnig