[PD-dev] PDINSTANCE for Pd (was Re: call for discussion double-precision file extension)

Dan Wilcox danomatika at gmail.com
Mon Apr 4 16:44:08 CEST 2022


Mmmm I wouldn't make this assumption. By default, the libpd repo makefile throws in LIBDL when linking on platforms that support it, so desktop apps *could* support loading externals. I for one, however, have not relied on this myself, but I could imagine *someone, somewhere* does? 

> On Apr 4, 2022, at 3:01 PM, pd-dev-request at lists.iem.at wrote:
> 
> Message: 2
> Date: Mon, 4 Apr 2022 15:00:52 +0200
> From: Christof Ressi <info at christofressi.com <mailto:info at christofressi.com>>
> To: pd-dev at lists.iem.at <mailto:pd-dev at lists.iem.at>
> Subject: Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion
> 	double-precision file extension)
> Message-ID: <0861a01f-14da-166c-df62-d8cebe2ed823 at christofressi.com <mailto:0861a01f-14da-166c-df62-d8cebe2ed823 at christofressi.com>>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
>> 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.

--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220404/dd644201/attachment.htm>


More information about the Pd-dev mailing list