The easiest thing would be to put all those objects directly in the extra folder.
Martin
From: Phil Stone pkstone@ucdavis.edu To: PD list pd-list@iem.at Subject: Re: [PD] sending OSC bundles. + help files? Date: Fri, 12 Sep 2008 10:34:48 -0700
Phil Stone wrote:
Hans-Christoph Steiner wrote:
The idea is to embed the library settings into the patch. In Pd-0.40.3-extended, if you added this to the patch, it would work for any Pd-0.40.3-extended install:
[import mrpeach]
Or could use Miller's declare, but I don't remember what the state of the declare bugs were in 0.41.4. It would be something like:
[declare -lib mrpeach]
or maybe
[declare -stdpath extra/mrpeach]
.hc
Just to be clear, does this mean if I use [import] in a patch, it becomes incompatible with vanilla Pd? Or can [import] be um, imported into vanilla Pd?
I apologize for following-up my own post, but this is a fairly important point, and I think it needs clarification. I'm about to release an abstraction, and I used [import] to eliminate a few dozen [mrpeach/...] style invocations of Martin Peach's OSC objects. Up until now, my abstraction would work with vanilla Pd if a couple of externals/libs were included (mrpeach being one of them). Have I now completely blocked out any vanilla Pd users by using [import]?
Of course, I could use [declare], but I've seen some questions about [declare] bugs on this list.
Is my only choice to go back to the redundant (and rather ugly) [mrpeach/routeOSC] style, in order to be compatible with vanilla Pd?
Is it rude to ask why we are essentially forking a very useful object? Is there any possibility of this being resolved into one, compatible object?
Phil Stone www.pkstonemusic.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list