On Sep 12, 2008, at 2:45 PM, Frank Barknecht wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
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]?AFAIK [import] is an external, for vanilla users it would just be an additional dependency to install.
Another problem, maybe bigger problem, is that using [import] like in pd-extended requires a certain directory layout. For example to make [import mrpeach] work in that it makes [routeOSC] availabe, pd-vanilla users not only need [import], they also have to put routeOSC.pd_linux|dll|... into a directory "mrpeach" in their path
(e.g. into "extra") to let [import mrpeach] actually load [routeOSC].But the problem is not as big as I make it. E.g. vanilla users
could use an empty abstraction import.pd and keep Martin's objects in the Pd- path directly. They are available as [routeOSC],... directly then.
Having the empty import.pd will make Pd shut up when [import mrpeach] is used and you could use [routeOSC] without prefix just fine. You could not use [mrpeach/routeOSC] then, but you don't want to anyway. ;)
Or even easier, just copy the "mrpeach" folder in extra from a Pd-
extended build into your Pd-vanilla install's extra folder. Done.
Then you can use namespace prefixes too, like [mrpeach/routeOSC].
.hc
Ciao
Frank Barknecht
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic