r 4, 2022, at 3:01 PM, pd-dev-requ...@lists.iem.at wrote:
>
> Message: 2
> Date: Mon, 4 Apr 2022 15:00:52 +0200
> From: Christof Ressi mailto:i...@christofressi.com>>
> To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] PDINSTANCE fo
(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
On 04.04.2022 15:49, Antoine Rousseau wrote:
ABI break for multi-instance libpd
only 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
>
> 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
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
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
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_*
-
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
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?
