[PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ?
Dan Wilcox
danomatika at gmail.com
Wed Apr 22 23:30:20 CEST 2015
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 at 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 at 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#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 <msp at 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 at 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 at gmail.com <mailto:danomatika at 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 at lists.iem.at <mailto:pd-dev-request at lists.iem.at> wrote:
>>>>>>>>>
>>>>>>>>> From: Oliver Greschke <info at o-g-sus.de <mailto:info at 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 at lists.iem.at <mailto:pd-dev at 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 at o-g-sus.de <mailto:info at o-g-sus.de>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pd-dev mailing list
>>>>>>>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>>>>>>>> http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pd-dev mailing list
>>>>>>> Pd-dev at lists.iem.at
>>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>>>
>>>>>
>>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> http://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150422/6e45865c/attachment-0001.html>
More information about the Pd-dev
mailing list