[PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ?

Miller Puckette msp at ucsd.edu
Sat Apr 25 04:25:57 CEST 2015


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 at 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 at 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 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
> 



More information about the Pd-dev mailing list