I'm guessing that this is not the desired solution (probably won't work on Android or any other platforms that use Processing), but perhaps it's worth mentioning that pd and Processing sketches can communicate via OSC messages. Both the pd patch and the Processing sketch would have to be modified, but they would be running independently of one another, so loading the externals wouldn't be an issue.
This solution could work well for a simple desktop application (although it's not embedded and maybe less convenient).
I'm not sure why compiling externals for use with Processing would be any more difficult than compiling for Android, though, which from my understanding only involves changing a flag or two in a makefile.
-Brian Fay
On Mon, Aug 5, 2013 at 11:19 AM, Dan Wilcox danomatika@gmail.com wrote:
It's not discussed as much because you have to rebuild libpd with the externals for Java which is not so easy, especially if you haven't done it before. Your best bet is to use an abstraction library that works with pd vanilla. rjlib https://github.com/rjdj/rjlib for instance, has both a resonant low pass filter and a ead~ replacement: [e_reslop] & [c_ead].
libpd is pd-vanilla, so IMO, it's best to approach it in that way unless you can add externals directly to your project. Even then, targeting vanilla means maximum portability. Libs like rjlib really help make that not so painful ...
On Aug 5, 2013, at 6:00 AM, pd-list-request@iem.at wrote:
*From: *Òscar Martínez Carmona xamps23@gmail.com *Subject: **[PD] libpd and Processing; handling externals* *Date: *August 5, 2013 2:14:43 AM EDT *To: *"pd-list@iem.at" pd-list@iem.at
Hi list! I'm aware that libpd and Processing are not the subjects more related to this list but I've asked this were it's suposed to be; "Pd-everywhere" 's threat at Create Digital Noise without any reply by now, so I'm trying it here. Libpd and Processing work really fine together and embedding PD patchs in Processing apps (and even making them standalone) it's quite easy: cool! The thing is that externals don't seem to work when used in the patch. That happens also whith libpd on iOS or Android aswell, but the solution is well doccumented and nicely solved in the (awesome) "Making Musical Apps" book by Peter Brinkmann. I haven't found any solution to this in the Processing environment by now, does anybody know how to proceed? I'm using the lipbp5 Processing's version of libpd in OSX 10.7 and more preciselly using the [moog~] and [ead~] externals. Thanx!
-- Òscar Martínez Carmona
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
In fact before embedding pd into the sketch with libpd, I was using OSC to communicate it with the patch on Pdextended. As Brian says I wasn't having those externals issues, but embedding the patch and building and standalone application is my goal by now, so I guess I'll use the rjlib's abstraction collection that Dan suggests. Anyways, do you know where I can find information on how to build the externals the "painful" way? Maybe someday I'll take a look at it! Thanx both guys!
On Mon, Aug 5, 2013 at 6:07 AM, Brian Fay ovaltinevortex@gmail.com wrote:
I'm guessing that this is not the desired solution (probably won't work on Android or any other platforms that use Processing), but perhaps it's worth mentioning that pd and Processing sketches can communicate via OSC messages. Both the pd patch and the Processing sketch would have to be modified, but they would be running independently of one another, so loading the externals wouldn't be an issue.
This solution could work well for a simple desktop application (although it's not embedded and maybe less convenient).
I'm not sure why compiling externals for use with Processing would be any more difficult than compiling for Android, though, which from my understanding only involves changing a flag or two in a makefile.
-Brian Fay
On Mon, Aug 5, 2013 at 11:19 AM, Dan Wilcox danomatika@gmail.com wrote:
It's not discussed as much because you have to rebuild libpd with the externals for Java which is not so easy, especially if you haven't done it before. Your best bet is to use an abstraction library that works with pd vanilla. rjlib https://github.com/rjdj/rjlib for instance, has both a resonant low pass filter and a ead~ replacement: [e_reslop] & [c_ead].
libpd is pd-vanilla, so IMO, it's best to approach it in that way unless you can add externals directly to your project. Even then, targeting vanilla means maximum portability. Libs like rjlib really help make that not so painful ...
On Aug 5, 2013, at 6:00 AM, pd-list-request@iem.at wrote:
*From: *Òscar Martínez Carmona xamps23@gmail.com *Subject: **[PD] libpd and Processing; handling externals* *Date: *August 5, 2013 2:14:43 AM EDT *To: *"pd-list@iem.at" pd-list@iem.at
Hi list! I'm aware that libpd and Processing are not the subjects more related to this list but I've asked this were it's suposed to be; "Pd-everywhere" 's threat at Create Digital Noise without any reply by now, so I'm trying it here. Libpd and Processing work really fine together and embedding PD patchs in Processing apps (and even making them standalone) it's quite easy: cool! The thing is that externals don't seem to work when used in the patch. That happens also whith libpd on iOS or Android aswell, but the solution is well doccumented and nicely solved in the (awesome) "Making Musical Apps" book by Peter Brinkmann. I haven't found any solution to this in the Processing environment by now, does anybody know how to proceed? I'm using the lipbp5 Processing's version of libpd in OSX 10.7 and more preciselly using the [moog~] and [ead~] externals. Thanx!
-- Òscar Martínez Carmona
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Brian Fay -
Òscar Martínez Carmona