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