Aha, thanks for pointing that out... 

I think it will be necessary to make various "ifdef" differences between
pdlib and Pd vanilla.  Even if this socket problem could be fixed with a
runtime flag, there remain thread-safety changes that I believe can't be
resolved without breakng binary compatibility with Pd vanilla.

So to return to Iohannes's question, yes, I think there could be a pd.so
compile target added to Pd vanilla - but I can't tell in advance if Pd can
me made multi-thread-capable and maintain binary compatible with existing
externs.  I think I or somebody will just have to try to code it and see
what's possible.

cheers
Miller


On Thu, Jan 05, 2017 at 10:02:36AM +0000, Giulio Moro via Pd-list wrote:
> Speaking of Bela, we have also been using libpd for the past nine months or 
> so. Some modifications were necessary to allow Xenomai to perform at its 
> best.  https://github.com/BelaPlatform/libpd/
> The most important was to take the `sys_microsleep()` out of PROCESS(_x, _y) 
> in z_libpd.c : this was performing socket I/O in the audio thread, and this 
> is bad practice in general, but particularly dangerous when using 
> Xenomai.This broke [netreceive] and until recently we relied on the libpd API 
> to replace it.I did some work last month for a threaded [netreceive] which 
> uses a ringbuffer. https://github.com/giuliomoro/pure-data/tree/Bela-net 
> (still work-in-progress)I think this is a reasonable solution (surely for us, 
> perhaps for others?) in that network communication is by definition not 
> deterministic, so having it in the audio thread did not make it any better.
> Other modifications involved taking the minimum blocksize down to 8 samples 
> and implement threading for [sigmund~] (still hacky). In the future I'll want 
> to implement threading for all vanilla objects which process large blocks of 
> samples at a time (e.g.: fft~, fiddle~), as previously discussed on this 
> list: https://lists.puredata.info/pipermail/pd-list/2016-09/116224.html
> 
> 
> 
> 
>  
>       From: Scott R. Looney <[email protected]>
>  To: pd-list <[email protected]> 
>  Sent: Thursday, 5 January 2017, 9:07
>  Subject: Re: [PD] include libpd? (Re: plans for Pd 0.48)
>    
> actually, i was curious about that myself but sort of on both tangents. at 
> the higher end i'm using Unity and PD vanilla via Kalimba and would 
> definitely like to use it without involving too much extra as it is in that 
> situation. 
> but the embedded factor is pretty important too. i've been checking out Bela 
> which has to compile PD patches using Heavy as well as using Xenomai to make 
> PD work efficiently (and Heavy doesn't support a lot of objects at the 
> moment). i would imagine that Johannes Taelmann was considering something 
> like PD for his Axoloti but couldn't make it work performance wise and so 
> decided to roll his own graphic patching setup instead.
> best,scott
> On Wed, Jan 4, 2017 at 10:17 AM, Peter Nyboer <[email protected]> wrote:
> 
> 
> > another wishlist from my side (which I wanted to address at PdCon16~ but
> > somehow didn't manage).
> > would it be possible to include the libpd glue into the proper Pd sources?
> 
> Funny - I had a somewhat tangential thought this morning. Something to the 
> effect of it being easier to deploy libpd on embedded devices. I haven’t 
> really looked into it very deeply, hence my uncertainly about whether or not 
> it’s easy, but I know it’s not “juzt 1 klik!” (oh, yeah, I went there).
> 
> Peter
> ______________________________ _________________
> [email protected] mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
> listinfo/pd-list
> 
> 
> 
> _______________________________________________
> [email protected] mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 
> 
>    
>  

> _______________________________________________
> [email protected] mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to