[PD-dev] Can somebody help to create a desktop / VST / AU version of a PD / libPD / app ?
Dan Wilcox
danomatika at gmail.com
Mon Apr 27 23:40:01 CEST 2015
Also, to follow up, I’ve adapted the multiple instance C example to C++ using ofxPd & openFrameworks and I’m seeing basically the same output. People have been chomping at the bit for this, so we’ll let it loose and see what happens next. :D
https://github.com/danomatika/ofxPd/tree/master/pdMultiExample/src <https://github.com/danomatika/ofxPd/tree/master/pdMultiExample/src>
--------
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Apr 27, 2015, at 5:17 PM, Dan Wilcox <danomatika at gmail.com> wrote:
>
> 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 <danomatika at gmail.com <mailto:danomatika at gmail.com>> 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 <msp at ucsd.edu <mailto:msp at ucsd.edu>> 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 <msp at ucsd.edu <mailto: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/> <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 <msp at ucsd.edu <mailto: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/>> <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 <msp at ucsd.edu <mailto: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/> <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 <msp at ucsd.edu <mailto: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> <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 <msp at ucsd.edu <mailto:msp at ucsd.edu>> 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 <k.s.matheussen at gmail.com <mailto: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> <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> <mailto: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> <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, pd-dev-request at lists.iem.at <mailto:pd-dev-request at lists.iem.at> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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 <mailto:Pd-dev at lists.iem.at>
>>>>>>>> http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150427/fc706e8a/attachment-0001.html>
More information about the Pd-dev
mailing list