We haven't completed really integrating the new changes in libpd yet ala an official libpd_* API that should help with these kinds of issues. If you run in good ways to isolate the instance calls so problems don't happen, let us know.
Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least.
On Aug 14, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
I'm using libpd master: 9a0bbd2a2b461c8345d5df5e9d347510b37756db
Any ideas whats up? I used to explicitly load the libpd.so into its own memory space from a unique temp file and that worked but wasn't ideal. Real multi instance support is going to be nice once I can get that going :) It seems like it must be an initialization or compile flag issue?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Note: There is currently an issue with the pd sources and libpd: https://github.com/pure-data/pure-data/issues/180 https://github.com/pure-data/pure-data/issues/180
On Aug 14, 2017, at 12:52 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Ahh, okay. Maybe I'll see about running libpd with a slightly older pure-data source submodule.. Thanks for the heads up! -Alex
On Mon, Aug 14, 2017 at 4:29 AM, Dan Wilcox danomatika@gmail.com wrote:
Note: There is currently an issue with the pd sources and libpd: https://github.com/pure-data/pure-data/issues/180
On Aug 14, 2017, at 12:52 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
The build issue is fixed and libpd is now using pd 0.48-0. No official release yet, but you can try the current master branch.
On Aug 14, 2017, at 6:59 PM, Alex x37v.alex@gmail.com wrote:
Ahh, okay. Maybe I'll see about running libpd with a slightly older pure-data source submodule.. Thanks for the heads up! -Alex
On Mon, Aug 14, 2017 at 4:29 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: Note: There is currently an issue with the pd sources and libpd: https://github.com/pure-data/pure-data/issues/180 https://github.com/pure-data/pure-data/issues/180
On Aug 14, 2017, at 12:52 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Hey,
I did the update and that, or moving my call to create a pd_instance to after libpd_init() resolved my issue.. Now my problem is that I have multiple different plugins using libpd in the same memory space and I'm not sure if: 1) is it safe to call libpd_init() multiple times, potentially while pd_instances exist and might be executing in another thread? 2) is there any way to see if libpd has been intialized and not call libpd_init() ? libpd_bind("PDLV2-TEST"); and before calling libpd_init I'd test.. if (libpd_exists("PDLV2-TEST") != 0) but that causes a segfault now.. maybe I just need to submit a bug report for that.
Thanks! Alex
On Thu, Aug 17, 2017 at 5:27 PM, Dan Wilcox danomatika@gmail.com wrote:
The build issue is fixed and libpd is now using pd 0.48-0. No official release yet, but you can try the current master branch.
On Aug 14, 2017, at 6:59 PM, Alex x37v.alex@gmail.com wrote:
Ahh, okay. Maybe I'll see about running libpd with a slightly older pure-data source submodule.. Thanks for the heads up! -Alex
On Mon, Aug 14, 2017 at 4:29 AM, Dan Wilcox danomatika@gmail.com wrote:
Note: There is currently an issue with the pd sources and libpd: https://github.com/pure-data/pure-data/issues/180
On Aug 14, 2017, at 12:52 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Yeah, we haven't integrated the new stuff into the libpd api yet. Look at the multi instance example in c/samples.
On Aug 18, 2017, at 5:45 PM, Alex x37v.alex@gmail.com wrote:
Hey,
I did the update and that, or moving my call to create a pd_instance to after libpd_init() resolved my issue.. Now my problem is that I have multiple different plugins using libpd in the same memory space and I'm not sure if:
- is it safe to call libpd_init() multiple times, potentially while pd_instances exist and might be executing in another thread?
- is there any way to see if libpd has been intialized and not call libpd_init() ? libpd_bind("PDLV2-TEST"); and before calling libpd_init I'd test.. if (libpd_exists("PDLV2-TEST") != 0)
but that causes a segfault now.. maybe I just need to submit a bug report for that.
Thanks! Alex
On Thu, Aug 17, 2017 at 5:27 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: The build issue is fixed and libpd is now using pd 0.48-0. No official release yet, but you can try the current master branch.
On Aug 14, 2017, at 6:59 PM, Alex <x37v.alex@gmail.com mailto:x37v.alex@gmail.com> wrote:
Ahh, okay. Maybe I'll see about running libpd with a slightly older pure-data source submodule.. Thanks for the heads up! -Alex
On Mon, Aug 14, 2017 at 4:29 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: Note: There is currently an issue with the pd sources and libpd: https://github.com/pure-data/pure-data/issues/180 https://github.com/pure-data/pure-data/issues/180
On Aug 14, 2017, at 12:52 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
yeah, that is what I based my changes off of. What all needs to be done to integrate the new 'stuff'? Maybe I'd try my hand at it. Is the goal to switch pd instances before calling the libpd calls or pass a pd_instance to the libpd calls? -Alex
On Fri, Aug 18, 2017 at 8:54 AM, Dan Wilcox danomatika@gmail.com wrote:
Yeah, we haven't integrated the new stuff into the libpd api yet. Look at the multi instance example in c/samples.
On Aug 18, 2017, at 5:45 PM, Alex x37v.alex@gmail.com wrote:
Hey,
I did the update and that, or moving my call to create a pd_instance to after libpd_init() resolved my issue.. Now my problem is that I have multiple different plugins using libpd in the same memory space and I'm not sure if:
- is it safe to call libpd_init() multiple times, potentially while
pd_instances exist and might be executing in another thread? 2) is there any way to see if libpd has been intialized and not call libpd_init() ? libpd_bind("PDLV2-TEST"); and before calling libpd_init I'd test.. if (libpd_exists("PDLV2-TEST") != 0) but that causes a segfault now.. maybe I just need to submit a bug report for that.
Thanks! Alex
On Thu, Aug 17, 2017 at 5:27 PM, Dan Wilcox danomatika@gmail.com wrote:
The build issue is fixed and libpd is now using pd 0.48-0. No official release yet, but you can try the current master branch.
On Aug 14, 2017, at 6:59 PM, Alex x37v.alex@gmail.com wrote:
Ahh, okay. Maybe I'll see about running libpd with a slightly older pure-data source submodule.. Thanks for the heads up! -Alex
On Mon, Aug 14, 2017 at 4:29 AM, Dan Wilcox danomatika@gmail.com wrote:
Note: There is currently an issue with the pd sources and libpd: https://github.com/pure-data/pure-data/issues/180
On Aug 14, 2017, at 12:52 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the current pd sources are not up to date with the 0.48 release. I will do that for now at least.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Something like that. The simplest solution is to just wrap pd_setinstance as libpd_setinstance, etc. Miller updated the pd_multi sample since you may have last seen it...
On Aug 18, 2017, at 6:29 PM, Alex x37v.alex@gmail.com wrote:
Is the goal to switch pd instances before calling the libpd calls or pass a pd_instance to the libpd calls?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Also, libpd_init currently just returns a -1 if it's already been inited once before, so you can call it multiple times.
On Aug 18, 2017, at 6:30 PM, Dan Wilcox danomatika@gmail.com wrote:
Something like that. The simplest solution is to just wrap pd_setinstance as libpd_setinstance, etc. Miller updated the pd_multi sample since you may have last seen it...
On Aug 18, 2017, at 6:29 PM, Alex <x37v.alex@gmail.com mailto:x37v.alex@gmail.com> wrote:
Is the goal to switch pd instances before calling the libpd calls or pass a pd_instance to the libpd calls?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
oh great, if I can call libpd_init multiple times that is great. I'll look at the pd_multi again too,. THANKS!
On Fri, Aug 18, 2017 at 9:32 AM, Dan Wilcox danomatika@gmail.com wrote:
Also, libpd_init currently just returns a -1 if it's already been inited once before, so you can call it multiple times.
On Aug 18, 2017, at 6:30 PM, Dan Wilcox danomatika@gmail.com wrote:
Something like that. The simplest solution is to just wrap pd_setinstance as libpd_setinstance, etc. Miller updated the pd_multi sample since you may have last seen it...
On Aug 18, 2017, at 6:29 PM, Alex x37v.alex@gmail.com wrote:
Is the goal to switch pd instances before calling the libpd calls or pass a pd_instance to the libpd calls?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
One more thing, the new instance support means the C layer now uses sys_lock, so we longer need locks or synchronization in the language wrappers. We haven't updating any of that yet so if you're using C++, you can build it without the mutex with the compile define.
Similarly, I have a working libpd.dll builtin minnow which works in Visual Studio. This necessitated making the C++ wrapper header-only. I haven't integrated that into the master branch yet either.
SO some changes coming, but probably not right away...
On Aug 18, 2017, at 6:36 PM, Alex x37v.alex@gmail.com wrote:
oh great, if I can call libpd_init multiple times that is great. I'll look at the pd_multi again too,. THANKS!
On Fri, Aug 18, 2017 at 9:32 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: Also, libpd_init currently just returns a -1 if it's already been inited once before, so you can call it multiple times.
On Aug 18, 2017, at 6:30 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Something like that. The simplest solution is to just wrap pd_setinstance as libpd_setinstance, etc. Miller updated the pd_multi sample since you may have last seen it...
On Aug 18, 2017, at 6:29 PM, Alex <x37v.alex@gmail.com mailto:x37v.alex@gmail.com> wrote:
Is the goal to switch pd instances before calling the libpd calls or pass a pd_instance to the libpd calls?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
eh, I'm not sure if i enabled the mutex before.. Thanks Dan!
On Fri, Aug 18, 2017 at 9:42 AM, Dan Wilcox danomatika@gmail.com wrote:
One more thing, the new instance support means the C layer now uses sys_lock, so we longer need locks or synchronization in the language wrappers. We haven't updating any of that yet so if you're using C++, you can build it without the mutex with the compile define.
Similarly, I have a working libpd.dll builtin minnow which works in Visual Studio. This necessitated making the C++ wrapper header-only. I haven't integrated that into the master branch yet either.
SO some changes coming, but probably not right away...
On Aug 18, 2017, at 6:36 PM, Alex x37v.alex@gmail.com wrote:
oh great, if I can call libpd_init multiple times that is great. I'll look at the pd_multi again too,. THANKS!
On Fri, Aug 18, 2017 at 9:32 AM, Dan Wilcox danomatika@gmail.com wrote:
Also, libpd_init currently just returns a -1 if it's already been inited once before, so you can call it multiple times.
On Aug 18, 2017, at 6:30 PM, Dan Wilcox danomatika@gmail.com wrote:
Something like that. The simplest solution is to just wrap pd_setinstance as libpd_setinstance, etc. Miller updated the pd_multi sample since you may have last seen it...
On Aug 18, 2017, at 6:29 PM, Alex x37v.alex@gmail.com wrote:
Is the goal to switch pd instances before calling the libpd calls or pass a pd_instance to the libpd calls?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
-
Alex -
Dan Wilcox