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 <[email protected]> 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 <[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] >>> <mailto:[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/>> <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 <[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
