[PD] include libpd? (Re: plans for Pd 0.48)

[Giulio Moro]

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 <scottrlooney at gmail.com>
 To: pd-list <pd-list at lists.iem.at> 
 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 <p at nbor.us> 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
______________________________ _________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list



_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list


   
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170105/ae6693b7/attachment.html>