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 <[email protected]> > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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#L33 > >>>>>>> > >>>>>>> <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 <[email protected]> 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 > >>>>>>>>>> <[email protected]> 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 <[email protected] > >>>>>>>>>> <mailto:[email protected]>> 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, [email protected] > >>>>>>>>>>> <mailto:[email protected]> wrote: > >>>>>>>>>>> > >>>>>>>>>>> From: Oliver Greschke <[email protected] <mailto:[email protected]>> > >>>>>>>>>>> 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: [email protected] <mailto:[email protected]> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Pd-dev mailing list > >>>>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>>>> http://lists.puredata.info/listinfo/pd-dev > >>>>>>>>>> <http://lists.puredata.info/listinfo/pd-dev> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Pd-dev mailing list > >>>>>>>>> [email protected] > >>>>>>>>> http://lists.puredata.info/listinfo/pd-dev > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Pd-dev mailing list > >>>> [email protected] > >>>> http://lists.puredata.info/listinfo/pd-dev > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
