Re: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ?
This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
Also, the main reason why we haven’t added this to libpd directly was it still seemed a work in progress. -------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:42 AM, Dan Wilcox danomatika@gmail.com wrote:
This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox danomatika@gmail.com wrote:
This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at wrote:
*From: *Oliver Greschke info@o-g-sus.de *Subject: **[PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ?* *Date: *April 21, 2015 at 3:15:44 AM EDT *To: *pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Probably, but I feel there should be some consistency in the api aka at least a libpd_set_instance() and some simple checking to make sure you don’t shoot yourself in the foot. There also needs to be an explanation in the wiki including information on how to use it in a multi threaded setup, etc. It’s not just a simple case of “let it loose” in libpd, but how to do so which involves beginners using libpd who have little/no multi threaded architecture background. If done wrong, the libpd Github get’s flooded with “help me” issues :P
I was hoping the “let it loose” thread on this list would have gone a bit farther so any/all bugs might have been found out by now. To go at it. -------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
Howdy Miller,
Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi
The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:
Here's how I modified libpd_wrapper/z_libpd.c:
55d54 < sys_time = 0; 110c109
< sched_tick(sys_time + sys_time_per_dsp_tick);
sched_tick();
130c129
< sched_tick(sys_time + sys_time_per_dsp_tick); \
sched_tick(); \
Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3
Here’s a gdb backtrace:
#0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 #5 0x0000000100095021 in sched_tick () at m_sched.c:418 #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 #7 0x0000000100000d18 in main ()
If I don’t optimize, it works fine:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
Hi Dan et al -
I gave this a try:
git clone https://github.com/libpd/libpd.git
[copies pd sources into libpd/pure-data]
cd libpd make
cd samples/c_samples/multi/ make ./multi_pdtest multi_test.pd `pwd`
and got output:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
This on Fedora 21, 64 bits, Intel hardware.
I guess something subtle is happening, maybe in Pd and unrelated to libpd?
cheers Miller
On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote:
Howdy Miller,
Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi
The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:
Here's how I modified libpd_wrapper/z_libpd.c:
55d54 < sys_time = 0; 110c109
< sched_tick(sys_time + sys_time_per_dsp_tick);
sched_tick();
130c129
< sched_tick(sys_time + sys_time_per_dsp_tick); \
sched_tick(); \Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3
Here’s a gdb backtrace:
#0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 #5 0x0000000100095021 in sched_tick () at m_sched.c:418 #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 #7 0x0000000100000d18 in main ()
If I don’t optimize, it works fine:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding:
cd ../../../ && make clobber && cd - && make -------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote:
Hi Dan et al -
I gave this a try:
git clone https://github.com/libpd/libpd.git
[copies pd sources into libpd/pure-data]
cd libpd make
cd samples/c_samples/multi/ make ./multi_pdtest multi_test.pd `pwd`
and got output:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
This on Fedora 21, 64 bits, Intel hardware.
I guess something subtle is happening, maybe in Pd and unrelated to libpd?
cheers Miller
On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote:
Howdy Miller,
Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi
The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:
Here's how I modified libpd_wrapper/z_libpd.c:
55d54 < sys_time = 0; 110c109
< sched_tick(sys_time + sys_time_per_dsp_tick);
sched_tick();
130c129
< sched_tick(sys_time + sys_time_per_dsp_tick); \
sched_tick(); \Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3
Here’s a gdb backtrace:
#0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 #5 0x0000000100095021 in sched_tick () at m_sched.c:418 #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 #7 0x0000000100000d18 in main ()
If I don’t optimize, it works fine:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
I think it was optimized since I had already made libpd, not from the sampes/.../multi directory. But anyhow I re-did it as you suggest with the same result.... can't make it fail...
cheers M
On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote:
You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding:
cd ../../../ && make clobber && cd - && make
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote:
Hi Dan et al -
I gave this a try:
git clone https://github.com/libpd/libpd.git
[copies pd sources into libpd/pure-data]
cd libpd make
cd samples/c_samples/multi/ make ./multi_pdtest multi_test.pd `pwd`
and got output:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
This on Fedora 21, 64 bits, Intel hardware.
I guess something subtle is happening, maybe in Pd and unrelated to libpd?
cheers Miller
On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote:
Howdy Miller,
Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi
The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:
Here's how I modified libpd_wrapper/z_libpd.c:
55d54 < sys_time = 0; 110c109
< sched_tick(sys_time + sys_time_per_dsp_tick);
sched_tick();
130c129
< sched_tick(sys_time + sys_time_per_dsp_tick); \
sched_tick(); \Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3
Here’s a gdb backtrace:
#0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 #5 0x0000000100095021 in sched_tick () at m_sched.c:418 #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 #7 0x0000000100000d18 in main ()
If I don’t optimize, it works fine:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3.
*Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi
Rebuilding and running it again yields:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next)
#0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 #5 0x0000000100000d67 in main ()
some frame detail:
(gdb) frame 0 #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) frame 1 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 363 pd_bang(oc->oc_to); (gdb) frame 2 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 162 outlet_bang(x->x_obj.ob_outlet); (gdb) frame 3 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 418 (*c->c_fn)(c->c_owner); (gdb) frame 4 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 185 PROCESS(,) (gdb) frame 5 #5 0x0000000100000d67 in main ()
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote:
I think it was optimized since I had already made libpd, not from the sampes/.../multi directory. But anyhow I re-did it as you suggest with the same result.... can't make it fail...
cheers M
On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote:
You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding:
cd ../../../ && make clobber && cd - && make
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote:
Hi Dan et al -
I gave this a try:
git clone https://github.com/libpd/libpd.git
[copies pd sources into libpd/pure-data]
cd libpd make
cd samples/c_samples/multi/ make ./multi_pdtest multi_test.pd `pwd`
and got output:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
This on Fedora 21, 64 bits, Intel hardware.
I guess something subtle is happening, maybe in Pd and unrelated to libpd?
cheers Miller
On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote:
Howdy Miller,
Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi
The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:
Here's how I modified libpd_wrapper/z_libpd.c:
55d54 < sys_time = 0; 110c109
< sched_tick(sys_time + sys_time_per_dsp_tick);
sched_tick();
130c129
< sched_tick(sys_time + sys_time_per_dsp_tick); \
sched_tick(); \
Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3
Here’s a gdb backtrace:
#0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 #5 0x0000000100095021 in sched_tick () at m_sched.c:418 #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 #7 0x0000000100000d18 in main ()
If I don’t optimize, it works fine:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? Date: April 21, 2015 at 3:15:44 AM EDT To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
Hi, I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). It’s made with PureData, libPD and Objective-C. I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app.
As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD
Has somebody here some experience with doing such ports? Then please contact me.
Cheers, Oliver
info@o-g-sus.de mailto:info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Aha - sometimes things crash on OSX because of "minor" buffer overruns that linux just soldiers past. I'll break out a mac and try again...
M
On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote:
Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3.
*Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi
Rebuilding and running it again yields:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next)
#0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 #5 0x0000000100000d67 in main ()
some frame detail:
(gdb) frame 0 #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) frame 1 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 363 pd_bang(oc->oc_to); (gdb) frame 2 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 162 outlet_bang(x->x_obj.ob_outlet); (gdb) frame 3 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 418 (*c->c_fn)(c->c_owner); (gdb) frame 4 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 185 PROCESS(,) (gdb) frame 5 #5 0x0000000100000d67 in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote:
I think it was optimized since I had already made libpd, not from the sampes/.../multi directory. But anyhow I re-did it as you suggest with the same result.... can't make it fail...
cheers M
On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote:
You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding:
cd ../../../ && make clobber && cd - && make
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote:
Hi Dan et al -
I gave this a try:
git clone https://github.com/libpd/libpd.git
[copies pd sources into libpd/pure-data]
cd libpd make
cd samples/c_samples/multi/ make ./multi_pdtest multi_test.pd `pwd`
and got output:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
This on Fedora 21, 64 bits, Intel hardware.
I guess something subtle is happening, maybe in Pd and unrelated to libpd?
cheers Miller
On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote:
Howdy Miller,
Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi
The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:
Here's how I modified libpd_wrapper/z_libpd.c:
55d54 < sys_time = 0; 110c109
< sched_tick(sys_time + sys_time_per_dsp_tick);
> sched_tick();
130c129
< sched_tick(sys_time + sys_time_per_dsp_tick); \
> sched_tick(); \
Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3
Here’s a gdb backtrace:
#0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 #5 0x0000000100095021 in sched_tick () at m_sched.c:418 #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 #7 0x0000000100000d18 in main ()
If I don’t optimize, it works fine:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
But for libpd, are you sure you need to add anything? Can't just the user call the pdinstance_new and pd_setinstance functions directly?
http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html
(BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, but since I didn't have all details in my head then, I didn't mention it. I should have though.)
On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html
I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ > On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote: > > From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> > Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? > Date: April 21, 2015 at 3:15:44 AM EDT > To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at > > > Hi, > I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). > It’s made with PureData, libPD and Objective-C. > I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. > > As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD > > Has somebody here some experience with doing such ports? > Then please contact me. > > Cheers, > Oliver > > info@o-g-sus.de mailto:info@o-g-sus.de
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
OK ... I think I fixed it... pull newest from git and try.
thanks M
On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote:
Aha - sometimes things crash on OSX because of "minor" buffer overruns that linux just soldiers past. I'll break out a mac and try again...
M
On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote:
Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3.
*Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi
Rebuilding and running it again yields:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next)
#0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 #5 0x0000000100000d67 in main ()
some frame detail:
(gdb) frame 0 #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) frame 1 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 363 pd_bang(oc->oc_to); (gdb) frame 2 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 162 outlet_bang(x->x_obj.ob_outlet); (gdb) frame 3 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 418 (*c->c_fn)(c->c_owner); (gdb) frame 4 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 185 PROCESS(,) (gdb) frame 5 #5 0x0000000100000d67 in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote:
I think it was optimized since I had already made libpd, not from the sampes/.../multi directory. But anyhow I re-did it as you suggest with the same result.... can't make it fail...
cheers M
On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote:
You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding:
cd ../../../ && make clobber && cd - && make
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote:
Hi Dan et al -
I gave this a try:
git clone https://github.com/libpd/libpd.git
[copies pd sources into libpd/pure-data]
cd libpd make
cd samples/c_samples/multi/ make ./multi_pdtest multi_test.pd `pwd`
and got output:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
This on Fedora 21, 64 bits, Intel hardware.
I guess something subtle is happening, maybe in Pd and unrelated to libpd?
cheers Miller
On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote:
Howdy Miller,
Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi
The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:
> Here's how I modified libpd_wrapper/z_libpd.c: > > 55d54 > < sys_time = 0; > 110c109 > < sched_tick(sys_time + sys_time_per_dsp_tick); > --- >> > sched_tick(); > > 130c129 > < sched_tick(sys_time + sys_time_per_dsp_tick); \ > --- >> > sched_tick(); \
Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3
Here’s a gdb backtrace:
#0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 #5 0x0000000100095021 in sched_tick () at m_sched.c:418 #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 #7 0x0000000100000d18 in main ()
If I don’t optimize, it works fine:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ > On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote: > > But for libpd, are you sure you need to add anything? Can't just the user > call the pdinstance_new and pd_setinstance functions directly? > > http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html > > > (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, > but since I didn't have all details in my head then, I didn't mention it. I should have though.) > > > On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: > This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html > > I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. > > -------- > Dan Wilcox > @danomatika > danomatika.com http://danomatika.com/ > robotcowboy.com http://robotcowboy.com/ >> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote: >> >> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> >> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >> Date: April 21, 2015 at 3:15:44 AM EDT >> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at >> >> >> Hi, >> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >> It’s made with PureData, libPD and Objective-C. >> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >> >> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >> >> Has somebody here some experience with doing such ports? >> Then please contact me. >> >> Cheers, >> Oliver >> >> info@o-g-sus.de mailto:info@o-g-sus.de > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at > http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev > >
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Thanks. Unfortunately still a crash, but now at a different place. I also confirmed that it still runs fine when libpd is compiled with -O3 aka make DEBUG=true.
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 #7 0x0000000100000b8f in main ()
In detail:
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 1 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 2 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 569 ugen_stop(); (gdb) frame 3 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 1086 ugen_start(); (gdb) frame 4 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); (gdb) frame 5 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 6 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 7 #7 0x0000000100000b8f in main ()
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 5:12 PM, Miller Puckette msp@ucsd.edu wrote:
OK ... I think I fixed it... pull newest from git and try.
thanks M
On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote:
Aha - sometimes things crash on OSX because of "minor" buffer overruns that linux just soldiers past. I'll break out a mac and try again...
M
On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote:
Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3.
*Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi
Rebuilding and running it again yields:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next)
#0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 #5 0x0000000100000d67 in main ()
some frame detail:
(gdb) frame 0 #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) frame 1 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 363 pd_bang(oc->oc_to); (gdb) frame 2 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 162 outlet_bang(x->x_obj.ob_outlet); (gdb) frame 3 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 418 (*c->c_fn)(c->c_owner); (gdb) frame 4 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 185 PROCESS(,) (gdb) frame 5 #5 0x0000000100000d67 in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote:
I think it was optimized since I had already made libpd, not from the sampes/.../multi directory. But anyhow I re-did it as you suggest with the same result.... can't make it fail...
cheers M
On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote:
You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding:
cd ../../../ && make clobber && cd - && make
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote:
Hi Dan et al -
I gave this a try:
git clone https://github.com/libpd/libpd.git
[copies pd sources into libpd/pure-data]
cd libpd make
cd samples/c_samples/multi/ make ./multi_pdtest multi_test.pd `pwd`
and got output:
print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
This on Fedora 21, 64 bits, Intel hardware.
I guess something subtle is happening, maybe in Pd and unrelated to libpd?
cheers Miller
On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote: > Howdy Miller, > > Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi > > The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: > >> Here's how I modified libpd_wrapper/z_libpd.c: >> >> 55d54 >> < sys_time = 0; >> 110c109 >> < sched_tick(sys_time + sys_time_per_dsp_tick); >> --- >>> >> sched_tick(); >> >> 130c129 >> < sched_tick(sys_time + sys_time_per_dsp_tick); \ >> --- >>> >> sched_tick(); \ > > > Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3 > > Here’s a gdb backtrace: > > #0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 > #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 > #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 > #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 > #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 > #5 0x0000000100095021 in sched_tick () at m_sched.c:418 > #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 > #7 0x0000000100000d18 in main () > > If I don’t optimize, it works fine: > > print: 0 > 1003-frequency: bang > print: 0 > 1004-frequency: bang > 1003-frequency: 1 > 1004-frequency: 2 > 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 > 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 > print: 1 > 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 > print: 1 > 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 > print: 2 > print: 2 > > -------- > Dan Wilcox > @danomatika > danomatika.com http://danomatika.com/ > robotcowboy.com http://robotcowboy.com/ >> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote: >> >> But for libpd, are you sure you need to add anything? Can't just the user >> call the pdinstance_new and pd_setinstance functions directly? >> >> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html >> >> >> (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, >> but since I didn't have all details in my head then, I didn't mention it. I should have though.) >> >> >> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: >> This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html >> >> I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com http://danomatika.com/ >> robotcowboy.com http://robotcowboy.com/ >>> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote: >>> >>> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> >>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >>> Date: April 21, 2015 at 3:15:44 AM EDT >>> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at >>> >>> >>> Hi, >>> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >>> It’s made with PureData, libPD and Objective-C. >>> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >>> >>> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >>> >>> Has somebody here some experience with doing such ports? >>> Then please contact me. >>> >>> Cheers, >>> Oliver >>> >>> info@o-g-sus.de mailto:info@o-g-sus.de >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev >> >> >
> _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at > http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Hmm... and (just checking) - you did a make clean and rebuilt everything? The pd_instance structure changed....
I can't get it to fail over here any more...
cheers Miller
On Wed, Apr 22, 2015 at 05:30:20PM -0400, Dan Wilcox wrote:
Thanks. Unfortunately still a crash, but now at a different place. I also confirmed that it still runs fine when libpd is compiled with -O3 aka make DEBUG=true.
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 #7 0x0000000100000b8f in main ()
In detail:
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 1 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 2 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 569 ugen_stop(); (gdb) frame 3 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 1086 ugen_start(); (gdb) frame 4 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); (gdb) frame 5 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 6 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 7 #7 0x0000000100000b8f in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 5:12 PM, Miller Puckette msp@ucsd.edu wrote:
OK ... I think I fixed it... pull newest from git and try.
thanks M
On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote:
Aha - sometimes things crash on OSX because of "minor" buffer overruns that linux just soldiers past. I'll break out a mac and try again...
M
On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote:
Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3.
*Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi
Rebuilding and running it again yields:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next)
#0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 #5 0x0000000100000d67 in main ()
some frame detail:
(gdb) frame 0 #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) frame 1 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 363 pd_bang(oc->oc_to); (gdb) frame 2 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 162 outlet_bang(x->x_obj.ob_outlet); (gdb) frame 3 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 418 (*c->c_fn)(c->c_owner); (gdb) frame 4 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 185 PROCESS(,) (gdb) frame 5 #5 0x0000000100000d67 in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote:
I think it was optimized since I had already made libpd, not from the sampes/.../multi directory. But anyhow I re-did it as you suggest with the same result.... can't make it fail...
cheers M
On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote:
You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding:
cd ../../../ && make clobber && cd - && make
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ > On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote: > > Hi Dan et al - > > I gave this a try: > > git clone https://github.com/libpd/libpd.git > > [copies pd sources into libpd/pure-data] > > cd libpd > make > > cd samples/c_samples/multi/ > make > ./multi_pdtest multi_test.pd `pwd` > > and got output: > > print: 0 > 1003-frequency: bang > print: 0 > 1004-frequency: bang > 1003-frequency: 1 > 1004-frequency: 2 > 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 > 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 > print: 1 > 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 > print: 1 > 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 > print: 2 > print: 2 > > This on Fedora 21, 64 bits, Intel hardware. > > I guess something subtle is happening, maybe in Pd and unrelated to libpd? > > cheers > Miller > > On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote: >> Howdy Miller, >> >> Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi >> >> The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: >> >>> Here's how I modified libpd_wrapper/z_libpd.c: >>> >>> 55d54 >>> < sys_time = 0; >>> 110c109 >>> < sched_tick(sys_time + sys_time_per_dsp_tick); >>> --- >>>> >>> sched_tick(); >>> >>> 130c129 >>> < sched_tick(sys_time + sys_time_per_dsp_tick); \ >>> --- >>>> >>> sched_tick(); \ >> >> >> Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3 >> >> Here’s a gdb backtrace: >> >> #0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 >> #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 >> #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 >> #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 >> #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 >> #5 0x0000000100095021 in sched_tick () at m_sched.c:418 >> #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 >> #7 0x0000000100000d18 in main () >> >> If I don’t optimize, it works fine: >> >> print: 0 >> 1003-frequency: bang >> print: 0 >> 1004-frequency: bang >> 1003-frequency: 1 >> 1004-frequency: 2 >> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >> print: 1 >> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >> print: 1 >> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >> print: 2 >> print: 2 >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com http://danomatika.com/ >> robotcowboy.com http://robotcowboy.com/ >>> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote: >>> >>> But for libpd, are you sure you need to add anything? Can't just the user >>> call the pdinstance_new and pd_setinstance functions directly? >>> >>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html >>> >>> >>> (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, >>> but since I didn't have all details in my head then, I didn't mention it. I should have though.) >>> >>> >>> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: >>> This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html >>> >>> I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. >>> >>> -------- >>> Dan Wilcox >>> @danomatika >>> danomatika.com http://danomatika.com/ >>> robotcowboy.com http://robotcowboy.com/ >>>> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote: >>>> >>>> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> >>>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >>>> Date: April 21, 2015 at 3:15:44 AM EDT >>>> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at >>>> >>>> >>>> Hi, >>>> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >>>> It’s made with PureData, libPD and Objective-C. >>>> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >>>> >>>> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >>>> >>>> Has somebody here some experience with doing such ports? >>>> Then please contact me. >>>> >>>> Cheers, >>>> Oliver >>>> >>>> info@o-g-sus.de mailto:info@o-g-sus.de >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >>> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev >>> >>> >> > >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at >> http://lists.puredata.info/listinfo/pd-dev >
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Actually yeah, looks good. Is there anyway this particular patch can be backported to the 0.46-6 release? Or will there be a 0.46-7 coming up soon? I ask because I’m having libpd checkout pure-data release tags. Not a huge deal if not, since this is still in testing.
Just to confirm:
Current git log for the pure-data sources I’m using:
danomatika:pure-data dano$ git log commit 35151c473827260c86cc864cc4cd058b24e67139 Author: Miller Puckette msp@ucsd.edu Date: Wed Apr 22 14:06:36 2015 -0700
make list of signals local to a pd instance to fix libpd crasher
Performed:
cd libpd make clobber make cd samples/c/pdtest_multi make clobber make ./pdtest_multi test.pd ./
Got:
start 80c04a90 stop 80c04a90 continue start 80c04a90 stop 80c04a90 print: 0 1003-frequency: bang start 80c04a90 stop 80c04a90 continue start 80c04a90 start 80c04db0 stop 80c04db0 continue start 80c04db0 stop 80c04db0 print: 0 1004-frequency: bang start 80c04db0 stop 80c04db0 continue start 80c04db0 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
I got the same response with building libpd with & without -03.
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 8:27 PM, Miller Puckette msp@ucsd.edu wrote:
Hmm... and (just checking) - you did a make clean and rebuilt everything? The pd_instance structure changed....
I can't get it to fail over here any more...
cheers Miller
On Wed, Apr 22, 2015 at 05:30:20PM -0400, Dan Wilcox wrote:
Thanks. Unfortunately still a crash, but now at a different place. I also confirmed that it still runs fine when libpd is compiled with -O3 aka make DEBUG=true.
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 #7 0x0000000100000b8f in main ()
In detail:
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 1 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 2 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 569 ugen_stop(); (gdb) frame 3 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 1086 ugen_start(); (gdb) frame 4 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); (gdb) frame 5 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 6 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 7 #7 0x0000000100000b8f in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
On Apr 22, 2015, at 5:12 PM, Miller Puckette msp@ucsd.edu wrote:
OK ... I think I fixed it... pull newest from git and try.
thanks M
On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote:
Aha - sometimes things crash on OSX because of "minor" buffer overruns that linux just soldiers past. I'll break out a mac and try again...
M
On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote:
Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3.
*Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi
Rebuilding and running it again yields:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next)
#0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 #5 0x0000000100000d67 in main ()
some frame detail:
(gdb) frame 0 #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) frame 1 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 363 pd_bang(oc->oc_to); (gdb) frame 2 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 162 outlet_bang(x->x_obj.ob_outlet); (gdb) frame 3 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 418 (*c->c_fn)(c->c_owner); (gdb) frame 4 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 185 PROCESS(,) (gdb) frame 5 #5 0x0000000100000d67 in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote:
I think it was optimized since I had already made libpd, not from the sampes/.../multi directory. But anyhow I re-did it as you suggest with the same result.... can't make it fail...
cheers M
On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote: > You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding: > > cd ../../../ && make clobber && cd - && make > -------- > Dan Wilcox > @danomatika > danomatika.com http://danomatika.com/ > robotcowboy.com http://robotcowboy.com/ >> On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote: >> >> Hi Dan et al - >> >> I gave this a try: >> >> git clone https://github.com/libpd/libpd.git >> >> [copies pd sources into libpd/pure-data] >> >> cd libpd >> make >> >> cd samples/c_samples/multi/ >> make >> ./multi_pdtest multi_test.pd `pwd` >> >> and got output: >> >> print: 0 >> 1003-frequency: bang >> print: 0 >> 1004-frequency: bang >> 1003-frequency: 1 >> 1004-frequency: 2 >> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >> print: 1 >> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >> print: 1 >> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >> print: 2 >> print: 2 >> >> This on Fedora 21, 64 bits, Intel hardware. >> >> I guess something subtle is happening, maybe in Pd and unrelated to libpd? >> >> cheers >> Miller >> >> On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote: >>> Howdy Miller, >>> >>> Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi >>> >>> The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: >>> >>>> Here's how I modified libpd_wrapper/z_libpd.c: >>>> >>>> 55d54 >>>> < sys_time = 0; >>>> 110c109 >>>> < sched_tick(sys_time + sys_time_per_dsp_tick); >>>> --- >>>>> >>>> sched_tick(); >>>> >>>> 130c129 >>>> < sched_tick(sys_time + sys_time_per_dsp_tick); \ >>>> --- >>>>> >>>> sched_tick(); \ >>> >>> >>> Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3 >>> >>> Here’s a gdb backtrace: >>> >>> #0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 >>> #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 >>> #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 >>> #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 >>> #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 >>> #5 0x0000000100095021 in sched_tick () at m_sched.c:418 >>> #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 >>> #7 0x0000000100000d18 in main () >>> >>> If I don’t optimize, it works fine: >>> >>> print: 0 >>> 1003-frequency: bang >>> print: 0 >>> 1004-frequency: bang >>> 1003-frequency: 1 >>> 1004-frequency: 2 >>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>> print: 1 >>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>> print: 1 >>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>> print: 2 >>> print: 2 >>> >>> -------- >>> Dan Wilcox >>> @danomatika >>> danomatika.com http://danomatika.com/ >>> robotcowboy.com http://robotcowboy.com/ >>>> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote: >>>> >>>> But for libpd, are you sure you need to add anything? Can't just the user >>>> call the pdinstance_new and pd_setinstance functions directly? >>>> >>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html >>>> >>>> >>>> (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, >>>> but since I didn't have all details in my head then, I didn't mention it. I should have though.) >>>> >>>> >>>> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: >>>> This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html >>>> >>>> I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. >>>> >>>> -------- >>>> Dan Wilcox >>>> @danomatika >>>> danomatika.com http://danomatika.com/ >>>> robotcowboy.com http://robotcowboy.com/ >>>>> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote: >>>>> >>>>> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> >>>>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >>>>> Date: April 21, 2015 at 3:15:44 AM EDT >>>>> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at >>>>> >>>>> >>>>> Hi, >>>>> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >>>>> It’s made with PureData, libPD and Objective-C. >>>>> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >>>>> >>>>> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >>>>> >>>>> Has somebody here some experience with doing such ports? >>>>> Then please contact me. >>>>> >>>>> Cheers, >>>>> Oliver >>>>> >>>>> info@o-g-sus.de mailto:info@o-g-sus.de >>>> >>>> _______________________________________________ >>>> Pd-dev mailing list >>>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >>>> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev >>>> >>>> >>> >> >>> _______________________________________________ >>> Pd-dev mailing list >>> Pd-dev@lists.iem.at >>> http://lists.puredata.info/listinfo/pd-dev >> >
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Finally but the bullet and tried this...
I made a branch, 0.46, adn committeed that and one other minor bug fix. The commit is 905695a350bf44d906fbb8cde905fa0b81d12b57
Too early in the game to make a 0.46-7 but I think if you track the 0.46 branch you'll be OK.
cheers Miller
On Thu, Apr 23, 2015 at 12:01:49AM -0400, Dan Wilcox wrote:
Actually yeah, looks good. Is there anyway this particular patch can be backported to the 0.46-6 release? Or will there be a 0.46-7 coming up soon? I ask because I’m having libpd checkout pure-data release tags. Not a huge deal if not, since this is still in testing.
Just to confirm:
Current git log for the pure-data sources I’m using:
danomatika:pure-data dano$ git log commit 35151c473827260c86cc864cc4cd058b24e67139 Author: Miller Puckette msp@ucsd.edu Date: Wed Apr 22 14:06:36 2015 -0700
make list of signals local to a pd instance to fix libpd crasherPerformed:
cd libpd make clobber make cd samples/c/pdtest_multi make clobber make ./pdtest_multi test.pd ./
Got:
start 80c04a90 stop 80c04a90 continue start 80c04a90 stop 80c04a90 print: 0 1003-frequency: bang start 80c04a90 stop 80c04a90 continue start 80c04a90 start 80c04db0 stop 80c04db0 continue start 80c04db0 stop 80c04db0 print: 0 1004-frequency: bang start 80c04db0 stop 80c04db0 continue start 80c04db0 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
I got the same response with building libpd with & without -03.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 8:27 PM, Miller Puckette msp@ucsd.edu wrote:
Hmm... and (just checking) - you did a make clean and rebuilt everything? The pd_instance structure changed....
I can't get it to fail over here any more...
cheers Miller
On Wed, Apr 22, 2015 at 05:30:20PM -0400, Dan Wilcox wrote:
Thanks. Unfortunately still a crash, but now at a different place. I also confirmed that it still runs fine when libpd is compiled with -O3 aka make DEBUG=true.
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 #7 0x0000000100000b8f in main ()
In detail:
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 1 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 2 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 569 ugen_stop(); (gdb) frame 3 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 1086 ugen_start(); (gdb) frame 4 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); (gdb) frame 5 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 6 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 7 #7 0x0000000100000b8f in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
On Apr 22, 2015, at 5:12 PM, Miller Puckette msp@ucsd.edu wrote:
OK ... I think I fixed it... pull newest from git and try.
thanks M
On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote:
Aha - sometimes things crash on OSX because of "minor" buffer overruns that linux just soldiers past. I'll break out a mac and try again...
M
On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote:
Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3.
*Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi
Rebuilding and running it again yields:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next)
#0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 #5 0x0000000100000d67 in main ()
some frame detail:
(gdb) frame 0 #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 388 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) frame 1 #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 363 pd_bang(oc->oc_to); (gdb) frame 2 #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 162 outlet_bang(x->x_obj.ob_outlet); (gdb) frame 3 #3 0x0000000100071010 in sched_tick () at m_sched.c:418 418 (*c->c_fn)(c->c_owner); (gdb) frame 4 #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 185 PROCESS(,) (gdb) frame 5 #5 0x0000000100000d67 in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ > On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote: > > I think it was optimized since I had already made libpd, not from the > sampes/.../multi directory. But anyhow I re-did it as you suggest with > the same result.... can't make it fail... > > cheers > M > > On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote: >> You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding: >> >> cd ../../../ && make clobber && cd - && make >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com http://danomatika.com/ >> robotcowboy.com http://robotcowboy.com/ >>> On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote: >>> >>> Hi Dan et al - >>> >>> I gave this a try: >>> >>> git clone https://github.com/libpd/libpd.git >>> >>> [copies pd sources into libpd/pure-data] >>> >>> cd libpd >>> make >>> >>> cd samples/c_samples/multi/ >>> make >>> ./multi_pdtest multi_test.pd `pwd` >>> >>> and got output: >>> >>> print: 0 >>> 1003-frequency: bang >>> print: 0 >>> 1004-frequency: bang >>> 1003-frequency: 1 >>> 1004-frequency: 2 >>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>> print: 1 >>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>> print: 1 >>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>> print: 2 >>> print: 2 >>> >>> This on Fedora 21, 64 bits, Intel hardware. >>> >>> I guess something subtle is happening, maybe in Pd and unrelated to libpd? >>> >>> cheers >>> Miller >>> >>> On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote: >>>> Howdy Miller, >>>> >>>> Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi >>>> >>>> The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: >>>> >>>>> Here's how I modified libpd_wrapper/z_libpd.c: >>>>> >>>>> 55d54 >>>>> < sys_time = 0; >>>>> 110c109 >>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); >>>>> --- >>>>>> >>>>> sched_tick(); >>>>> >>>>> 130c129 >>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); \ >>>>> --- >>>>>> >>>>> sched_tick(); \ >>>> >>>> >>>> Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3 >>>> >>>> Here’s a gdb backtrace: >>>> >>>> #0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 >>>> #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 >>>> #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 >>>> #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 >>>> #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 >>>> #5 0x0000000100095021 in sched_tick () at m_sched.c:418 >>>> #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 >>>> #7 0x0000000100000d18 in main () >>>> >>>> If I don’t optimize, it works fine: >>>> >>>> print: 0 >>>> 1003-frequency: bang >>>> print: 0 >>>> 1004-frequency: bang >>>> 1003-frequency: 1 >>>> 1004-frequency: 2 >>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>>> print: 1 >>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>>> print: 1 >>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>>> print: 2 >>>> print: 2 >>>> >>>> -------- >>>> Dan Wilcox >>>> @danomatika >>>> danomatika.com http://danomatika.com/ >>>> robotcowboy.com http://robotcowboy.com/ >>>>> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote: >>>>> >>>>> But for libpd, are you sure you need to add anything? Can't just the user >>>>> call the pdinstance_new and pd_setinstance functions directly? >>>>> >>>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html >>>>> >>>>> >>>>> (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, >>>>> but since I didn't have all details in my head then, I didn't mention it. I should have though.) >>>>> >>>>> >>>>> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: >>>>> This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html >>>>> >>>>> I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. >>>>> >>>>> -------- >>>>> Dan Wilcox >>>>> @danomatika >>>>> danomatika.com http://danomatika.com/ >>>>> robotcowboy.com http://robotcowboy.com/ >>>>>> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote: >>>>>> >>>>>> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> >>>>>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >>>>>> Date: April 21, 2015 at 3:15:44 AM EDT >>>>>> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at >>>>>> >>>>>> >>>>>> Hi, >>>>>> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >>>>>> It’s made with PureData, libPD and Objective-C. >>>>>> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >>>>>> >>>>>> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >>>>>> >>>>>> Has somebody here some experience with doing such ports? >>>>>> Then please contact me. >>>>>> >>>>>> Cheers, >>>>>> Oliver >>>>>> >>>>>> info@o-g-sus.de mailto:info@o-g-sus.de >>>>> >>>>> _______________________________________________ >>>>> Pd-dev mailing list >>>>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >>>>> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev >>>>> >>>>> >>>> >>> >>>> _______________________________________________ >>>> Pd-dev mailing list >>>> Pd-dev@lists.iem.at >>>> http://lists.puredata.info/listinfo/pd-dev >>> >>
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Ok, now tracking 0.46 branch. Thanks.
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 24, 2015, at 10:25 PM, Miller Puckette msp@ucsd.edu wrote:
Finally but the bullet and tried this...
I made a branch, 0.46, adn committeed that and one other minor bug fix. The commit is 905695a350bf44d906fbb8cde905fa0b81d12b57
Too early in the game to make a 0.46-7 but I think if you track the 0.46 branch you'll be OK.
cheers Miller
On Thu, Apr 23, 2015 at 12:01:49AM -0400, Dan Wilcox wrote:
Actually yeah, looks good. Is there anyway this particular patch can be backported to the 0.46-6 release? Or will there be a 0.46-7 coming up soon? I ask because I’m having libpd checkout pure-data release tags. Not a huge deal if not, since this is still in testing.
Just to confirm:
Current git log for the pure-data sources I’m using:
danomatika:pure-data dano$ git log commit 35151c473827260c86cc864cc4cd058b24e67139 Author: Miller Puckette msp@ucsd.edu Date: Wed Apr 22 14:06:36 2015 -0700
make list of signals local to a pd instance to fix libpd crasher
Performed:
cd libpd make clobber make cd samples/c/pdtest_multi make clobber make ./pdtest_multi test.pd ./
Got:
start 80c04a90 stop 80c04a90 continue start 80c04a90 stop 80c04a90 print: 0 1003-frequency: bang start 80c04a90 stop 80c04a90 continue start 80c04a90 start 80c04db0 stop 80c04db0 continue start 80c04db0 stop 80c04db0 print: 0 1004-frequency: bang start 80c04db0 stop 80c04db0 continue start 80c04db0 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
I got the same response with building libpd with & without -03.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 22, 2015, at 8:27 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
Hmm... and (just checking) - you did a make clean and rebuilt everything? The pd_instance structure changed....
I can't get it to fail over here any more...
cheers Miller
On Wed, Apr 22, 2015 at 05:30:20PM -0400, Dan Wilcox wrote:
Thanks. Unfortunately still a crash, but now at a different place. I also confirmed that it still runs fine when libpd is compiled with -O3 aka make DEBUG=true.
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 #7 0x0000000100000b8f in main ()
In detail:
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 1 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 2 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 569 ugen_stop(); (gdb) frame 3 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 1086 ugen_start(); (gdb) frame 4 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); (gdb) frame 5 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 6 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 7 #7 0x0000000100000b8f in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> <http://danomatika.com/ http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> <http://robotcowboy.com/ http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>>
On Apr 22, 2015, at 5:12 PM, Miller Puckette msp@ucsd.edu wrote:
OK ... I think I fixed it... pull newest from git and try.
thanks M
On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote:
Aha - sometimes things crash on OSX because of "minor" buffer overruns that linux just soldiers past. I'll break out a mac and try again...
M
On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote: > Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3. > > *Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi > > Rebuilding and running it again yields: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: 13 at address: 0x0000000000000000 > outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 > 388 for (oc = x->o_connections; oc; oc = oc->oc_next) > > #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 > #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 > #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 > #3 0x0000000100071010 in sched_tick () at m_sched.c:418 > #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 > #5 0x0000000100000d67 in main () > > some frame detail: > > (gdb) frame 0 > #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 > 388 for (oc = x->o_connections; oc; oc = oc->oc_next) > (gdb) frame 1 > #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 > 363 pd_bang(oc->oc_to); > (gdb) frame 2 > #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 > 162 outlet_bang(x->x_obj.ob_outlet); > (gdb) frame 3 > #3 0x0000000100071010 in sched_tick () at m_sched.c:418 > 418 (*c->c_fn)(c->c_owner); > (gdb) frame 4 > #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 > 185 PROCESS(,) > (gdb) frame 5 > #5 0x0000000100000d67 in main () > > -------- > Dan Wilcox > @danomatika > danomatika.com http://danomatika.com/ > robotcowboy.com http://robotcowboy.com/ >> On Apr 22, 2015, at 12:15 AM, Miller Puckette msp@ucsd.edu wrote: >> >> I think it was optimized since I had already made libpd, not from the >> sampes/.../multi directory. But anyhow I re-did it as you suggest with >> the same result.... can't make it fail... >> >> cheers >> M >> >> On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote: >>> You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 and do a full clean before rebuilding: >>> >>> cd ../../../ && make clobber && cd - && make >>> -------- >>> Dan Wilcox >>> @danomatika >>> danomatika.com http://danomatika.com/ >>> robotcowboy.com http://robotcowboy.com/ >>>> On Apr 21, 2015, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote: >>>> >>>> Hi Dan et al - >>>> >>>> I gave this a try: >>>> >>>> git clone https://github.com/libpd/libpd.git >>>> >>>> [copies pd sources into libpd/pure-data] >>>> >>>> cd libpd >>>> make >>>> >>>> cd samples/c_samples/multi/ >>>> make >>>> ./multi_pdtest multi_test.pd `pwd` >>>> >>>> and got output: >>>> >>>> print: 0 >>>> 1003-frequency: bang >>>> print: 0 >>>> 1004-frequency: bang >>>> 1003-frequency: 1 >>>> 1004-frequency: 2 >>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>>> print: 1 >>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>>> print: 1 >>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>>> print: 2 >>>> print: 2 >>>> >>>> This on Fedora 21, 64 bits, Intel hardware. >>>> >>>> I guess something subtle is happening, maybe in Pd and unrelated to libpd? >>>> >>>> cheers >>>> Miller >>>> >>>> On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote: >>>>> Howdy Miller, >>>>> >>>>> Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi >>>>> >>>>> The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: >>>>> >>>>>> Here's how I modified libpd_wrapper/z_libpd.c: >>>>>> >>>>>> 55d54 >>>>>> < sys_time = 0; >>>>>> 110c109 >>>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); >>>>>> --- >>>>>>> >>>>>> sched_tick(); >>>>>> >>>>>> 130c129 >>>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); \ >>>>>> --- >>>>>>> >>>>>> sched_tick(); \ >>>>> >>>>> >>>>> Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3 >>>>> >>>>> Here’s a gdb backtrace: >>>>> >>>>> #0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 >>>>> #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 >>>>> #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 >>>>> #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 >>>>> #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 >>>>> #5 0x0000000100095021 in sched_tick () at m_sched.c:418 >>>>> #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 >>>>> #7 0x0000000100000d18 in main () >>>>> >>>>> If I don’t optimize, it works fine: >>>>> >>>>> print: 0 >>>>> 1003-frequency: bang >>>>> print: 0 >>>>> 1004-frequency: bang >>>>> 1003-frequency: 1 >>>>> 1004-frequency: 2 >>>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>>>> print: 1 >>>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>>>> print: 1 >>>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>>>> print: 2 >>>>> print: 2 >>>>> >>>>> -------- >>>>> Dan Wilcox >>>>> @danomatika >>>>> danomatika.com http://danomatika.com/ >>>>> robotcowboy.com http://robotcowboy.com/ >>>>>> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen k.s.matheussen@gmail.com wrote: >>>>>> >>>>>> But for libpd, are you sure you need to add anything? Can't just the user >>>>>> call the pdinstance_new and pd_setinstance functions directly? >>>>>> >>>>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html >>>>>> >>>>>> >>>>>> (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, >>>>>> but since I didn't have all details in my head then, I didn't mention it. I should have though.) >>>>>> >>>>>> >>>>>> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: >>>>>> This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html >>>>>> >>>>>> I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. >>>>>> >>>>>> -------- >>>>>> Dan Wilcox >>>>>> @danomatika >>>>>> danomatika.com http://danomatika.com/ >>>>>> robotcowboy.com http://robotcowboy.com/ >>>>>>> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote: >>>>>>> >>>>>>> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de> >>>>>>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >>>>>>> Date: April 21, 2015 at 3:15:44 AM EDT >>>>>>> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >>>>>>> It’s made with PureData, libPD and Objective-C. >>>>>>> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >>>>>>> >>>>>>> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >>>>>>> >>>>>>> Has somebody here some experience with doing such ports? >>>>>>> Then please contact me. >>>>>>> >>>>>>> Cheers, >>>>>>> Oliver >>>>>>> >>>>>>> info@o-g-sus.de mailto:info@o-g-sus.de >>>>>> >>>>>> _______________________________________________ >>>>>> Pd-dev mailing list >>>>>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >>>>>> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev >>>>>> >>>>>> >>>>> >>>> >>>>> _______________________________________________ >>>>> Pd-dev mailing list >>>>> Pd-dev@lists.iem.at >>>>> http://lists.puredata.info/listinfo/pd-dev >>>> >>> >
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Is there any major overhead with pd_setinstance()? I ask as I’m thinking how to incorporate it into the C++ wrapper where each PdBase C++ instance refers to a separate pd instance, so that would basically mean alot of pd_setinstance() calls, basically one in every pdBase member function.
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 26, 2015, at 3:00 PM, Dan Wilcox danomatika@gmail.com wrote:
Ok, now tracking 0.46 branch. Thanks.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 24, 2015, at 10:25 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
Finally but the bullet and tried this...
I made a branch, 0.46, adn committeed that and one other minor bug fix. The commit is 905695a350bf44d906fbb8cde905fa0b81d12b57
Too early in the game to make a 0.46-7 but I think if you track the 0.46 branch you'll be OK.
cheers Miller
On Thu, Apr 23, 2015 at 12:01:49AM -0400, Dan Wilcox wrote:
Actually yeah, looks good. Is there anyway this particular patch can be backported to the 0.46-6 release? Or will there be a 0.46-7 coming up soon? I ask because I’m having libpd checkout pure-data release tags. Not a huge deal if not, since this is still in testing.
Just to confirm:
Current git log for the pure-data sources I’m using:
danomatika:pure-data dano$ git log commit 35151c473827260c86cc864cc4cd058b24e67139 Author: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Date: Wed Apr 22 14:06:36 2015 -0700
make list of signals local to a pd instance to fix libpd crasher
Performed:
cd libpd make clobber make cd samples/c/pdtest_multi make clobber make ./pdtest_multi test.pd ./
Got:
start 80c04a90 stop 80c04a90 continue start 80c04a90 stop 80c04a90 print: 0 1003-frequency: bang start 80c04a90 stop 80c04a90 continue start 80c04a90 start 80c04db0 stop 80c04db0 continue start 80c04db0 stop 80c04db0 print: 0 1004-frequency: bang start 80c04db0 stop 80c04db0 continue start 80c04db0 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
I got the same response with building libpd with & without -03.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
On Apr 22, 2015, at 8:27 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
Hmm... and (just checking) - you did a make clean and rebuilt everything? The pd_instance structure changed....
I can't get it to fail over here any more...
cheers Miller
On Wed, Apr 22, 2015 at 05:30:20PM -0400, Dan Wilcox wrote:
Thanks. Unfortunately still a crash, but now at a different place. I also confirmed that it still runs fine when libpd is compiled with -O3 aka make DEBUG=true.
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 #7 0x0000000100000b8f in main ()
In detail:
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 1 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 2 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 569 ugen_stop(); (gdb) frame 3 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 1086 ugen_start(); (gdb) frame 4 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); (gdb) frame 5 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 6 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 7 #7 0x0000000100000b8f in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> <http://danomatika.com/ http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> <http://robotcowboy.com/ http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>>
On Apr 22, 2015, at 5:12 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
OK ... I think I fixed it... pull newest from git and try.
thanks M
On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote: > Aha - sometimes things crash on OSX because of "minor" buffer overruns that > linux just soldiers past. I'll break out a mac and try again... > > M > > On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote: >> Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3. >> >> *Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi >> >> Rebuilding and running it again yields: >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: 13 at address: 0x0000000000000000 >> outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 >> 388 for (oc = x->o_connections; oc; oc = oc->oc_next) >> >> #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 >> #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 >> #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 >> #3 0x0000000100071010 in sched_tick () at m_sched.c:418 >> #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 >> #5 0x0000000100000d67 in main () >> >> some frame detail: >> >> (gdb) frame 0 >> #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 >> 388 for (oc = x->o_connections; oc; oc = oc->oc_next) >> (gdb) frame 1 >> #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 >> 363 pd_bang(oc->oc_to); >> (gdb) frame 2 >> #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 >> 162 outlet_bang(x->x_obj.ob_outlet); >> (gdb) frame 3 >> #3 0x0000000100071010 in sched_tick () at m_sched.c:418 >> 418 (*c->c_fn)(c->c_owner); >> (gdb) frame 4 >> #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 >> 185 PROCESS(,) >> (gdb) frame 5 >> #5 0x0000000100000d67 in main () >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>> On Apr 22, 2015, at 12:15 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote: >>> >>> I think it was optimized since I had already made libpd, not from the >>> sampes/.../multi directory. But anyhow I re-did it as you suggest with >>> the same result.... can't make it fail... >>> >>> cheers >>> M >>> >>> On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote: >>>> You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 <https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33> and do a full clean before rebuilding: >>>> >>>> cd ../../../ && make clobber && cd - && make >>>> -------- >>>> Dan Wilcox >>>> @danomatika >>>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >>>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>>>> On Apr 21, 2015, at 11:57 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote: >>>>> >>>>> Hi Dan et al - >>>>> >>>>> I gave this a try: >>>>> >>>>> git clone https://github.com/libpd/libpd.git https://github.com/libpd/libpd.git >>>>> >>>>> [copies pd sources into libpd/pure-data] >>>>> >>>>> cd libpd >>>>> make >>>>> >>>>> cd samples/c_samples/multi/ >>>>> make >>>>> ./multi_pdtest multi_test.pd `pwd` >>>>> >>>>> and got output: >>>>> >>>>> print: 0 >>>>> 1003-frequency: bang >>>>> print: 0 >>>>> 1004-frequency: bang >>>>> 1003-frequency: 1 >>>>> 1004-frequency: 2 >>>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>>>> print: 1 >>>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>>>> print: 1 >>>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>>>> print: 2 >>>>> print: 2 >>>>> >>>>> This on Fedora 21, 64 bits, Intel hardware. >>>>> >>>>> I guess something subtle is happening, maybe in Pd and unrelated to libpd? >>>>> >>>>> cheers >>>>> Miller >>>>> >>>>> On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote: >>>>>> Howdy Miller, >>>>>> >>>>>> Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi <https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi> >>>>>> >>>>>> The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: <http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:> >>>>>> >>>>>>> Here's how I modified libpd_wrapper/z_libpd.c: >>>>>>> >>>>>>> 55d54 >>>>>>> < sys_time = 0; >>>>>>> 110c109 >>>>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); >>>>>>> --- >>>>>>>> >>>>>>> sched_tick(); >>>>>>> >>>>>>> 130c129 >>>>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); \ >>>>>>> --- >>>>>>>> >>>>>>> sched_tick(); \ >>>>>> >>>>>> >>>>>> Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 <https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171> and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3 >>>>>> >>>>>> Here’s a gdb backtrace: >>>>>> >>>>>> #0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 >>>>>> #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 >>>>>> #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 >>>>>> #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 >>>>>> #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 >>>>>> #5 0x0000000100095021 in sched_tick () at m_sched.c:418 >>>>>> #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 >>>>>> #7 0x0000000100000d18 in main () >>>>>> >>>>>> If I don’t optimize, it works fine: >>>>>> >>>>>> print: 0 >>>>>> 1003-frequency: bang >>>>>> print: 0 >>>>>> 1004-frequency: bang >>>>>> 1003-frequency: 1 >>>>>> 1004-frequency: 2 >>>>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>>>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>>>>> print: 1 >>>>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>>>>> print: 1 >>>>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>>>>> print: 2 >>>>>> print: 2 >>>>>> >>>>>> -------- >>>>>> Dan Wilcox >>>>>> @danomatika >>>>>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >>>>>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>>>>>> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen <k.s.matheussen@gmail.com mailto:k.s.matheussen@gmail.com> wrote: >>>>>>> >>>>>>> But for libpd, are you sure you need to add anything? Can't just the user >>>>>>> call the pdinstance_new and pd_setinstance functions directly? >>>>>>> >>>>>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html <http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html> >>>>>>> >>>>>>> >>>>>>> (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, >>>>>>> but since I didn't have all details in my head then, I didn't mention it. I should have though.) >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com <mailto:danomatika@gmail.com mailto:danomatika@gmail.com>> wrote: >>>>>>> This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html <http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html> >>>>>>> >>>>>>> I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. >>>>>>> >>>>>>> -------- >>>>>>> Dan Wilcox >>>>>>> @danomatika >>>>>>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >>>>>>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>>>>>>> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at <mailto:pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at> wrote: >>>>>>>> >>>>>>>> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de <mailto:info@o-g-sus.de mailto:info@o-g-sus.de>> >>>>>>>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >>>>>>>> Date: April 21, 2015 at 3:15:44 AM EDT >>>>>>>> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >>>>>>>> It’s made with PureData, libPD and Objective-C. >>>>>>>> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >>>>>>>> >>>>>>>> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >>>>>>>> >>>>>>>> Has somebody here some experience with doing such ports? >>>>>>>> Then please contact me. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Oliver >>>>>>>> >>>>>>>> info@o-g-sus.de mailto:info@o-g-sus.de <mailto:info@o-g-sus.de mailto:info@o-g-sus.de> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pd-dev mailing list >>>>>>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at> >>>>>>> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>>> Pd-dev mailing list >>>>>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >>>>>> http://lists.puredata.info/listinfo/pd-dev >>>>> >>>> >> > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at > http://lists.puredata.info/listinfo/pd-dev
Also, to follow up, I’ve adapted the multiple instance C example to C++ using ofxPd & openFrameworks and I’m seeing basically the same output. People have been chomping at the bit for this, so we’ll let it loose and see what happens next. :D
https://github.com/danomatika/ofxPd/tree/master/pdMultiExample/src https://github.com/danomatika/ofxPd/tree/master/pdMultiExample/src
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 27, 2015, at 5:17 PM, Dan Wilcox danomatika@gmail.com wrote:
Is there any major overhead with pd_setinstance()? I ask as I’m thinking how to incorporate it into the C++ wrapper where each PdBase C++ instance refers to a separate pd instance, so that would basically mean alot of pd_setinstance() calls, basically one in every pdBase member function.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 26, 2015, at 3:00 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Ok, now tracking 0.46 branch. Thanks.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 24, 2015, at 10:25 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
Finally but the bullet and tried this...
I made a branch, 0.46, adn committeed that and one other minor bug fix. The commit is 905695a350bf44d906fbb8cde905fa0b81d12b57
Too early in the game to make a 0.46-7 but I think if you track the 0.46 branch you'll be OK.
cheers Miller
On Thu, Apr 23, 2015 at 12:01:49AM -0400, Dan Wilcox wrote:
Actually yeah, looks good. Is there anyway this particular patch can be backported to the 0.46-6 release? Or will there be a 0.46-7 coming up soon? I ask because I’m having libpd checkout pure-data release tags. Not a huge deal if not, since this is still in testing.
Just to confirm:
Current git log for the pure-data sources I’m using:
danomatika:pure-data dano$ git log commit 35151c473827260c86cc864cc4cd058b24e67139 Author: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Date: Wed Apr 22 14:06:36 2015 -0700
make list of signals local to a pd instance to fix libpd crasher
Performed:
cd libpd make clobber make cd samples/c/pdtest_multi make clobber make ./pdtest_multi test.pd ./
Got:
start 80c04a90 stop 80c04a90 continue start 80c04a90 stop 80c04a90 print: 0 1003-frequency: bang start 80c04a90 stop 80c04a90 continue start 80c04a90 start 80c04db0 stop 80c04db0 continue start 80c04db0 stop 80c04db0 print: 0 1004-frequency: bang start 80c04db0 stop 80c04db0 continue start 80c04db0 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2
I got the same response with building libpd with & without -03.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
On Apr 22, 2015, at 8:27 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
Hmm... and (just checking) - you did a make clean and rebuilt everything? The pd_instance structure changed....
I can't get it to fail over here any more...
cheers Miller
On Wed, Apr 22, 2015 at 05:30:20PM -0400, Dan Wilcox wrote:
Thanks. Unfortunately still a crash, but now at a different place. I also confirmed that it still runs fine when libpd is compiled with -O3 aka make DEBUG=true.
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 #7 0x0000000100000b8f in main ()
In detail:
#0 signal_cleanup [inlined] () at /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 1 #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 364 pd_this->pd_signals = sig->s_nextused; (gdb) frame 2 #2 0x000000010002670e in ugen_start () at d_ugen.c:569 569 ugen_stop(); (gdb) frame 3 #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value temporarily unavailable, due to optimizations>, argv=0x100102e20) at g_canvas.c:1086 1086 ugen_start(); (gdb) frame 4 #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, argv=0x100102e20) at m_class.c:699 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); (gdb) frame 5 #5 0x0000000100096fb8 in libpd_message [inlined] () at /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 6 #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 236 pd_typedmess(dest, gensym(msg), n, v); (gdb) frame 7 #7 0x0000000100000b8f in main ()
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> <http://danomatika.com/ http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> <http://robotcowboy.com/ http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>> > On Apr 22, 2015, at 5:12 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote: > > OK ... I think I fixed it... pull newest from git and try. > > thanks > M > > On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote: >> Aha - sometimes things crash on OSX because of "minor" buffer overruns that >> linux just soldiers past. I'll break out a mac and try again... >> >> M >> >> On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote: >>> Weird. It crashes for me on OSX when libpd is built with -O3 and the program is built with or without -O3. >>> >>> *Note: I just finished reorganizing the libpd samples by language name. If you do a pull, the multi instance test is now located in samples/c/pdtest_multi >>> >>> Rebuilding and running it again yields: >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: 13 at address: 0x0000000000000000 >>> outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 >>> 388 for (oc = x->o_connections; oc; oc = oc->oc_next) >>> >>> #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 >>> #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 >>> #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 >>> #3 0x0000000100071010 in sched_tick () at m_sched.c:418 >>> #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 >>> #5 0x0000000100000d67 in main () >>> >>> some frame detail: >>> >>> (gdb) frame 0 >>> #0 outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388 >>> 388 for (oc = x->o_connections; oc; oc = oc->oc_next) >>> (gdb) frame 1 >>> #1 0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to optimizations>) at m_obj.c:363 >>> 363 pd_bang(oc->oc_to); >>> (gdb) frame 2 >>> #2 0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162 >>> 162 outlet_bang(x->x_obj.ob_outlet); >>> (gdb) frame 3 >>> #3 0x0000000100071010 in sched_tick () at m_sched.c:418 >>> 418 (*c->c_fn)(c->c_owner); >>> (gdb) frame 4 >>> #4 0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value temporarily unavailable, due to optimizations>, outBuffer=<value temporarily unavailable, due to optimizations>) at z_libpd.c:185 >>> 185 PROCESS(,) >>> (gdb) frame 5 >>> #5 0x0000000100000d67 in main () >>> >>> -------- >>> Dan Wilcox >>> @danomatika >>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>>> On Apr 22, 2015, at 12:15 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote: >>>> >>>> I think it was optimized since I had already made libpd, not from the >>>> sampes/.../multi directory. But anyhow I re-did it as you suggest with >>>> the same result.... can't make it fail... >>>> >>>> cheers >>>> M >>>> >>>> On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote: >>>>> You ran it without the optimizations since I added the debug option. Remove DEBUG=true from line 33 in the Makefile: https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33 <https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#... https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33> and do a full clean before rebuilding: >>>>> >>>>> cd ../../../ && make clobber && cd - && make >>>>> -------- >>>>> Dan Wilcox >>>>> @danomatika >>>>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >>>>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>>>>> On Apr 21, 2015, at 11:57 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote: >>>>>> >>>>>> Hi Dan et al - >>>>>> >>>>>> I gave this a try: >>>>>> >>>>>> git clone https://github.com/libpd/libpd.git https://github.com/libpd/libpd.git >>>>>> >>>>>> [copies pd sources into libpd/pure-data] >>>>>> >>>>>> cd libpd >>>>>> make >>>>>> >>>>>> cd samples/c_samples/multi/ >>>>>> make >>>>>> ./multi_pdtest multi_test.pd `pwd` >>>>>> >>>>>> and got output: >>>>>> >>>>>> print: 0 >>>>>> 1003-frequency: bang >>>>>> print: 0 >>>>>> 1004-frequency: bang >>>>>> 1003-frequency: 1 >>>>>> 1004-frequency: 2 >>>>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>>>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>>>>> print: 1 >>>>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>>>>> print: 1 >>>>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>>>>> print: 2 >>>>>> print: 2 >>>>>> >>>>>> This on Fedora 21, 64 bits, Intel hardware. >>>>>> >>>>>> I guess something subtle is happening, maybe in Pd and unrelated to libpd? >>>>>> >>>>>> cheers >>>>>> Miller >>>>>> >>>>>> On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote: >>>>>>> Howdy Miller, >>>>>>> >>>>>>> Following up from the dev list last year, I added your multi instance test to the c samples included with libpd: https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi <https://github.com/libpd/libpd/tree/master/samples/c_samples/multi https://github.com/libpd/libpd/tree/master/samples/c_samples/multi> >>>>>>> >>>>>>> The one thing I want to double check is the changes to z_libpd.c you mentioned in http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: <http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:> >>>>>>> >>>>>>>> Here's how I modified libpd_wrapper/z_libpd.c: >>>>>>>> >>>>>>>> 55d54 >>>>>>>> < sys_time = 0; >>>>>>>> 110c109 >>>>>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); >>>>>>>> --- >>>>>>>>> >>>>>>>> sched_tick(); >>>>>>>> >>>>>>>> 130c129 >>>>>>>> < sched_tick(sys_time + sys_time_per_dsp_tick); \ >>>>>>>> --- >>>>>>>>> >>>>>>>> sched_tick(); \ >>>>>>> >>>>>>> >>>>>>> Currently, that line is https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 <https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171> and I’m getting a segfault if I replace it with sched_tick(); AND set gcc optimization to -O3 >>>>>>> >>>>>>> Here’s a gdb backtrace: >>>>>>> >>>>>>> #0 0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, f=0.999937057) at m_obj.c:388 >>>>>>> #1 0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89 >>>>>>> #2 0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267 >>>>>>> #3 0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363 >>>>>>> #4 0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162 >>>>>>> #5 0x0000000100095021 in sched_tick () at m_sched.c:418 >>>>>>> #6 0x00000001000c5d4d in libpd_process_float (ticks=1, inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173 >>>>>>> #7 0x0000000100000d18 in main () >>>>>>> >>>>>>> If I don’t optimize, it works fine: >>>>>>> >>>>>>> print: 0 >>>>>>> 1003-frequency: bang >>>>>>> print: 0 >>>>>>> 1004-frequency: bang >>>>>>> 1003-frequency: 1 >>>>>>> 1004-frequency: 2 >>>>>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 >>>>>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 >>>>>>> print: 1 >>>>>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 >>>>>>> print: 1 >>>>>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 >>>>>>> print: 2 >>>>>>> print: 2 >>>>>>> >>>>>>> -------- >>>>>>> Dan Wilcox >>>>>>> @danomatika >>>>>>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >>>>>>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>>>>>>> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen <k.s.matheussen@gmail.com mailto:k.s.matheussen@gmail.com> wrote: >>>>>>>> >>>>>>>> But for libpd, are you sure you need to add anything? Can't just the user >>>>>>>> call the pdinstance_new and pd_setinstance functions directly? >>>>>>>> >>>>>>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html <http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html> >>>>>>>> >>>>>>>> >>>>>>>> (BTW. When I wrote about libpds, I hadn't forgotten about the support for pd instances, >>>>>>>> but since I didn't have all details in my head then, I didn't mention it. I should have though.) >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com <mailto:danomatika@gmail.com mailto:danomatika@gmail.com>> wrote: >>>>>>>> This should be possible with the current version of libpd which includes Miller’s multiple instance updates, see http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html <http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html> >>>>>>>> >>>>>>>> I just haven’t gotten around to adding libpd-specific wrapper functions for this yet, but Miller provides code in that dev list exchange. >>>>>>>> >>>>>>>> -------- >>>>>>>> Dan Wilcox >>>>>>>> @danomatika >>>>>>>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> >>>>>>>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> >>>>>>>>> On Apr 21, 2015, at 6:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at <mailto:pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at> wrote: >>>>>>>>> >>>>>>>>> From: Oliver Greschke <info@o-g-sus.de mailto:info@o-g-sus.de <mailto:info@o-g-sus.de mailto:info@o-g-sus.de>> >>>>>>>>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ? >>>>>>>>> Date: April 21, 2015 at 3:15:44 AM EDT >>>>>>>>> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> I am the creator of the Elastic Drums iOS app (with great PD help from Matt Davey). >>>>>>>>> It’s made with PureData, libPD and Objective-C. >>>>>>>>> I got asked a couple of times now, if there will be ever a standalone desktop version or even better Plugin (VST, AU) version of the app. >>>>>>>>> >>>>>>>>> As far as I know, there are not ready to use workarounds to do so. Which is sad, because I can imagine a lot of fantastic plugins emerging from PD >>>>>>>>> >>>>>>>>> Has somebody here some experience with doing such ports? >>>>>>>>> Then please contact me. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Oliver >>>>>>>>> >>>>>>>>> info@o-g-sus.de mailto:info@o-g-sus.de <mailto:info@o-g-sus.de mailto:info@o-g-sus.de> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pd-dev mailing list >>>>>>>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at> >>>>>>>> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> Pd-dev mailing list >>>>>>> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >>>>>>> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev >>>>>> >>>>> >>> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at >> http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
-
Dan Wilcox -
Kjetil Matheussen -
Miller Puckette