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