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
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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
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%C2%A0(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@gmail.com>
To: pd-list pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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%C2%A0(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.htmlFrom: Scott R. Looney <scottrlooney@gmail.com>To: pd-list pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Giulio Moro -
Miller Puckette -
Peter Nyboer -
Scott R. Looney